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

[Halil Pasic]

On 01/09/2017 03:50 PM, Eric Blake wrote:
> 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

Thanks for the clarification. As a non-native speaker I find that usage
of "may" highly non-intuitive. Especially since in chapter 4.
"Conformance" (from n1124) does define how "shall" and "shall not" but
there is nothing on "may".

This way of saying macros expand to stuff that does not touch errno is
IMHO quite unfriendly (if this was really the intention - I think it is
quite likely that it was), and IMHO a more straight forward formulation
would benefit the standard.

> expansion if that macro does not expand to a documented function call).

It's clear that macro expansion itself does not modify program state, so
the question is to what is a library macro allowed to expand to.

> va_start() is usually not implemented as a function call, and even if it
> is, it is not a publicly documented function call.

IMHO whether it is implemented as a function (call) or a macro is irrelevant
here. Apparently library functions may be additionally implemented as a macro,
and library macros may be implemented as functions (7.2 "The assert macro
shall  be  implemented  as  a  macro,  not  as  an  actual  function").

Library macros can expand to stuff calling documented library functions
(7.2.1.1 "It then calls the abort function."), but this is also
irrelevant if we interpret that "may" as you explained. 


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

Thank you very much for making your point clear. I take away: "The value
of errno may be set to nonzero by a library function call" also
means/implies 'use of any library entity, which was not specified as a
library function, shall not set errno to nonzero'.  This really helps me
a lot because it answers the question which part of the standard
prohibits the va_* macros from clobbering errno.

I see this primarily as a C ISO standard problem, so I'm reluctant to
necro-bump that bug in order to start a discussion about how the C
standard is to be interpreted.  I'm going to ask some friends if it is
only me who finds it difficult to read that sentence as you propose.


Best Regards,
Halil

signature.asc
Description: OpenPGP digital signature