qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] error: error_setg_errno(): errno gets preserved
Date: Mon, 9 Jan 2017 15:13:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 01/09/2017 12:27 PM, Halil Pasic wrote:

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

Sadly, I'm not responsible for the wording in the C standard; I also
find it confusing sometimes, even as a native speaker.

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

Or better: "Use of any library entity which was not specified as a
library function shall not modify errno".  While most interfaces in the
library are functions (because they have required linkage) and may also
be a macro, there are some (like assert() and the va_* macros) which are
explicitly documented to be macros only.

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

Yes, you are probably right that raising an issue with the C authors may
be the best path forward on this topic, as it is certainly getting
beyond the bounds of what qemu cares about.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]