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
