Re: [Qemu-devel] [PATCH] error: error_setg_errno(): errno gets preserved

[Halil Pasic <pasic@linux.vnet.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 2153 bytes --]



On 07/28/2016 11:03 PM, Eric Blake wrote:
> On 07/28/2016 09:29 AM, Halil Pasic wrote:
> 
>>> You mean va_start, not start_va.  And actually, C11 is clear that errno
>>> is unspecified after library functions (but not macros) that don't
>>> explicitly state otherwise.  Since va_start() is a macro and not a
>>> library function, that means va_start does NOT have carte blanche
>>> permission to modify errno.  For more reading on the topic:
>>
>> I also considered this function/macro thing but in the end I am not
>> aware of anything in C11 what would prohibit va_start to modify errno --
>> correct me if I'm wrong. With that it boils down to 'may' and relying on
>> 'does not' means you are not covered by the standard C11 (but may
>> be covered by something else -- in which case this should be documented
>> in HACKING).
>>
>>>
>>> http://austingroupbugs.net/view.php?id=384
>>>
>>
>> This got rejected, or? Means that there is no willingness to introduce
>> this guarantee at POSIX level?
>>  
> 
> That particular bug report was rejected because the POSIX folks decided
> that the C11 wording was clear enough that va_start() was already
> guaranteed to not mess with errno, so no additionally wording was needed
> in POSIX.
> 

Sadly, I still do not get it. I have re-read the relevant parts of N1570
and even had a conversation with the in house compiler team. The
compiler guy's opinion was also that there is no guarantee provided by
C11. In http://austingroupbugs.net/view.php?id=384 you stated in the
description that the code example provided there is not conforming. Your
last reply I read like you were wrong with that statement. I still do
not understand why were you wrong there. In fact, I could argue that you
were right, but I'm afraid the argument would be somewhat lengthy and
confusing, and I'm already feeling bad about taking so much of your time
with this. Since I'm  admittedly quite inexperienced in this field I
decided to just accept your the conclusion you and the POSIX guys
reached -- without fully understanding it.

Thanks again for your time.

Regards,
Halil



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]