> And ISO and IEEE standards can't be "misguided" That's not a claim that I would ever make. But the right time to bring up objections is during the drafting o

> And ISO and IEEE standards can't be "misguided" That's not a claim that I would ever make. But the right time to bring up objections is during the drafting of the standard. If you aim to implement a standard you should have a very good reason before you implement some interface differently than specified. I would argue that these return values are not a good enough reason. gets(3) on the other hand would hardly be missed... > Undefined behavior is not defined, explicitly or otherwise. There can be explicit wording that some requirement is not being made. In C, undefined behavior has a quite specific meaning: invoking undefined behavior is an error in the program and the implementation is at liberty to do anything it pleases. "undefined behavior: behavior upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements." Your example of evaluation order is not undefined behavior, but unspecified behavior: there is a set of possible orderings and the implementation may pick any one of them.