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