[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
signature.asc
Description: OpenPGP digital signature