Yeah, if it's just an int, it should be OK.
The only difference between:
void foo( const char *bar )
{
std::cout << bar << std::endl;
}
and
int foo( const char *bar )
{
std::cout << bar << std::endl;
return 1;
}
is extra:
967: b8 01 00 00 00 mov $0x1,%eax
before:
96c: c9 leaveq
96d: c3 retq
Since you don't put anything on the stack you're good to go.
Cheers,
Lukasz
On 11/26/2014 02:21 PM, Elvin Alin Sindrilaru wrote:
>
> Hi all,
>
> I used the abi-compatibility-checker provided by RedHat and I attached the results.
> And as far as RedHat is concerned the two libraries are compatible when changing the return type from void to int ... so this should be good enough for EPEL, I guess ...
>
> Cheers,
> Elvin
>
> ________________________________________
> From: Lukasz Janyst
> Sent: 26 November 2014 10:42
> To: Elvin Alin Sindrilaru; [log in to unmask]
> Subject: Re: FW: Question on OFS interface
>
> 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
