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

[Eric Blake]

On 07/29/2016 08:38 AM, Halil Pasic wrote:
> 
> 
> 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.

The description was the initial claim, before I had consulted with the
rest of the Austin Group.  Yes, my initial claim was that POSIX needed
tightening to guarantee something not provided by C.

> Your
> last reply I read like you were wrong with that statement.

Correct - after consultation with the full Austin Group, my initial
claim was invalidated, and the reason it was invalidated was that the
C99 standard only permits arbitrary changes to errno after function
calls, and that the C99 definition of a function call does NOT include
macro expansions.  Therefore, POSIX does not need tightening, because
the guarantee I wanted is already present; the initial description in
that bug report is well-defined, rather than my claim of undefined.
Any compliant C implementation, and therefore all POSIX-compliant
implementations, already leave errno unchanged after any use of the
varags macros.  (The current version of POSIX is still stuck on C99,
although the Austin Group is just barely starting work to incorporate
C11 for the next version of POSIX.)

> 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.

The C99 standard is annoying in that it does not use the usual RFC
wording, so where C99 uses "may", many other standards (including POSIX)
use "shall" or even "shall only".  So the fact that C99 states that "The
value of errno may be set to nonzero by a library function call" is a
requirement that C can permit arbitrary modification of errno ONLY after
a function call, and not for any other reason (including after a macro
expansion if that macro does not expand to a documented function call).
va_start() is usually not implemented as a function call, and even if it
is, it is not a publicly documented function call.

But you are certainly welcome to add further comments to the Austin
Group bug, if you think anything was misinterpreted - in the end, the
intent IS that va_* are safe to use without arbitrary changes to errno,
and it is now just a matter of whether that intent is already met by C
wording or whether POSIX indeed needs to add an additional requirement.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature