4 ms·

I have not checked which syscall or libc function could return that, but it's quite possible that some applicable standard like C or POSIX or SUS mandates such

I have not checked which syscall or libc function could return that, but it's quite possible that some applicable standard like C or POSIX or SUS mandates such a return value. It is better to follow the standard in such cases, so that portable code written against the standard runs nicely. However (claims the OP) in the case of printf, the %s null pointer case is explicitly defined to be undefined behavior and hence the implementation should handle this either implicitly (by crashing with null pointer dereference) or explicitly by calling abort(), as that will teach programmers not to rely on superficially benign implementations of undefined behavior.

kazinator 11y ago
> mandates such a return value. And ISO and IEEE standards can't be "misguided", just competing operating systems that are more successful. > explicitly defined to be undefined behavior Contradiction. Undefined behavior is not defined, explicitly or otherwise. There can be explicit wording that some requirement is not being made. When ISO C explicitly states that there is an absence of a requirement, that does not carry any more or less weight then when behavior is undefined by omission of any wording of a requirement. All UB is equal. > not to rely on superficially benign implementations of undefined behavior. An excellent example of beneficially fixing undefined behavior is to implement strict left to right ordering on all operations and their side effects. A language or language dialect in which evaluation order is defined is safer and better for engineering.
- the_why_of_y 11y ago
  > 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.
  - deleted 11y ago
    [deleted]
  - kazinator 11y ago
    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. That doesn't match my understanding, which is that undefined behavior is about erroneous constructs or data, or non-portable constructs. Oh look, you quoted it. Thanks! Some undefined behaviors are important sources for useful, documented extensions.

kazinator 11y ago

> mandates such a return value. And ISO and IEEE standards can't be "misguided", just competing operating systems that are more successful. > explicitly defined to be undefined behavior Contradiction. Undefined behavior is not defined, explicitly or otherwise. There can be explicit wording that some requirement is not being made. When ISO C explicitly states that there is an absence of a requirement, that does not carry any more or less weight then when behavior is undefined by omission of any wording of a requirement. All UB is equal. > not to rely on superficially benign implementations of undefined behavior. An excellent example of beneficially fixing undefined behavior is to implement strict left to right ordering on all operations and their side effects. A language or language dialect in which evaluation order is defined is safer and better for engineering.

the_why_of_y 11y ago
> 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.
- deleted 11y ago
  [deleted]
- kazinator 11y ago
  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. That doesn't match my understanding, which is that undefined behavior is about erroneous constructs or data, or non-portable constructs. Oh look, you quoted it. Thanks! Some undefined behaviors are important sources for useful, documented extensions.