 |
 |
Thanks for the heads-up Lukasz. Indeed, this would then be a compiler optimization problem. If so, testing it on all the platforms is not sufficient. You would have to test it with compiler variants and different optimization levels. One can imagine that the compiler, seeing that it's a void return could use the presumptively unused area of the stack for something else -- leading to stack corruption in programs compiled against a declared void return but linked against a method that actually does place something on the stack. This has been one of the quibbles people have with C++; i.e. that the return type is not part of the signature. So, I think it's best we not change return type sizes in public methods. Let me see what else I can up with. Andy On Wed, 26 Nov 2014, Lukasz Janyst wrote: > In C++, the return code is not a part of function's signature, therefore, > in principle, it may be changed. Especially if it's from void to non-void, > because all the "legacy" callers did not expect anything to be returned, so > changing nothing to something should not matter. However, after some > googling, people seem to see some callstack corruptions that may be related > to this kind of change, so I would try it first on all supported platforms. > > Cheers, > Lukasz > > On 11/26/2014 10:34 AM, Elvin Alin Sindrilaru wrote: >> >> Forwarding this also to XRootD-dev mailing list. >> >> Cheers, >> Elvin >> >> ------------------------------------------------------------------------ >> *From:* Elvin Alin Sindrilaru >> *Sent:* 26 November 2014 10:06 >> *To:* Andrew Hanushevsky >> *Subject:* RE: Question on OFS interface >> >> >> Hi Andy, >> >> I talked with Lukasz about the ABI change and he said that the return >> type of a function is not part of the signature as far as EPEL is >> concerned - moreover since it was void it was ignored by the clients ... >> >> So, if it doesn't have any negative impact could you change its return >> type and also take it into consideration when calling it i.e. fail the >> loading if an error value is returned such as in XrdXrootdConfig.cc. >> >> Thanks, >> Elvin >> >> ------------------------------------------------------------------------ >> *From:* Andrew Hanushevsky [[log in to unmask]] >> *Sent:* 25 November 2014 22:41 >> *To:* Elvin Alin Sindrilaru >> *Subject:* Re: Question on OFS interface >> >> Hi Elvin, >> >> What is the purpose of XrdOfs::Config_Cluster method? I understand that >> one can pass an oss implementation but from what I see, it is not used >> anywhere in the XRootD code ... Is this intended for plugin developers >> to use? >>>>> Legacy code. We had a method where the cmsd could forward oss-type >>>>> requests to the xrootd so it needed a pointer to that plug-in. We >>>>> removed that capability because, frankly, it didn?t really work all that >>>>> well, especially when the xrootd was busy. You are of course, looking >>>>> at private code >> so anything that you think you can depend on you really can?t. I doubt >> it will be removed but it usually is set to zero. >> Another one would be whether it would be possible to have the >> XrdSfsFileSystem::EnvInfo method return an int or a boolean instead of >> void - to signal any possible errors while using/setting any internal >> state based on the new info provided? >> >>>Ah, unfortunately that likely not possible because that changes a >> public interface ? something we are not allowed to do (or we get kicked >> out of EPEL). You can ask Lukasz if changing a return type from void to >> non-void constitutes a real change in EPEL land (I?d say no but EPEL may >> have other rules). >> Andy >> >> ------------------------------------------------------------------------ >> >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >> > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-DEV list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1