And the mangled symbol is the same (as expected) in both cases: _Z3fooPKc
]==> c++filt _Z3fooPKc
foo(char const*)
Lukasz
On 11/26/2014 02:56 PM, Lukasz Janyst wrote:
> 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
