Hi Theo, Theo de Raadt wrote on Fri, Nov 17, 2017 at 10:43:10AM -0700: > Ingo Schwarze wrote:
>> I don't think, though, that the commit message should advertise >> this as a performance improvement. It should be called an intentional >> change of behaviour, now using the format string as a byte string >> like everyone else, no matter whether POSIX explicitly specifies >> it as a character string instead. > I do not agree with your position that POSIX calls this a character > string. http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html "The format is a character string, ..." Well, i does, and... > Pure and simply, it is a legacy char *, and any attempt to re-standardize > it from that would crash cars and other heavy equipment. ... given that POSIX-2008 is explicitly based on C99 and both C89 and C99 are even more explicit (see below), it follows that people thirty years ago probably intended to crash cars and other heavy equipment, even though you may quite possibly be right that it was likely a bad idea back then. > I'd like to mention in a previous email you used the term fail-closed > incorrectly. > > Returning an error number and changing behaviour (truncating) > when there there potentially isn't a caller-checks isn't fail-closed. > > Fail-closed implies the software crashes or terminates, so that the > bug can be inspected and fixed. > > Returning an error in a newer version of a standard, when a past > standard passed data straight though? > > With no way for authors to know the fallout, and requiring them to > audit all code for the broad practice of missing caller-checks? > Not realistic. Point taken. > So it would be responsible to assume a check can be here. I think > you have misread POSIX, or someone did 's/char/character/' too broadly. Todd's research revealed that jtc@ got the information from the C standard in 1995, so i just checked what C89 (sic!) says: 4.9.6.1 The fprintf function [...] The format shall be a multibyte character sequence, beginning and ending in its initial shift state. The format is composed of zero or more directives: ordinary multibyte characters (not % ), which are copied unchanged to the output stream; and conversion specifications, each of which results in fetching zero or more subsequent arguments. C99 says exactly the same in 7.19.6.1.3. That teaches me that i should stop trusting POSIX to accurately and clearly paraphrase the C standard. In 7.19.6.1.14, C99 then goes on to say: The fprintf function returns the number of characters transmitted, or a negative value if an output or encoding error occurred. That is even more explicit than POSIX, which only says: If an output error was encountered, these functions shall return a negative value and set errno to indicate the error. So C99 explicitly requires failure *for encoding errors* and explicitly requires multibyte encoding for the format string. So it appears that *everybody* (except us) is in blatant violation of C99. To hell with multibyte characters! How on earth do so many dragons fit into such a small rabbit hole! Sigh, Ingo
