OK, so referencing my previous post. Are you all really comfortable in
expecting that an int return will never put something on the stack or that
the compiler will never expect that the return register will be untouched
by a method returning a void (i.e. so that it optimizes by leaving a value
in that register to be used after the call)?
Andy
On Wed, 26 Nov 2014, Lukasz Janyst wrote:
> 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
>
########################################################################
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
|
