lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Mon, Sep 6, 2021 at 12:40 PM Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> -----------------------------------------------------
> 3.4.3
>
> 1 undefined behavior
>
> BEHAVIOR, upon use of a nonportable or erroneous program construct or of
> erroneous data, FOR WHICH THIS INTERNATIONAL STANDARD IMPOSES NO
> REQUIREMENTS

(Emphasis added.) This definition only adds to the confusion.

Saying nothing satisfies this definition: If something is not mentioned
by the standard, the standard obviously imposes no requirments, and
therefore that something is undefined behavior.

-- Roberto

The clause in the middle is not optional, and both must be satisfied. The standard must first state that a use is nonportable or erroneous, and then it must not prescribe a requirement upon what an implementation should do upon encountering such a program construct or data. If the standard does not state that a use is nonportable or erroneous, then the lack of specification means that it is, to use Lorenzo's terminology, plain UB, not UB(TM).

(To be fair, this means that the definition is grammatically incorrect according to the formal rules of academic English. The commas should have been omitted, as the appositive phrase "upon use of..." is essential to the meaning of "behavior.")

The broader interpretation would conflict with 3.4.1 "implementation-defined behavior" as the standard imposes no requirements upon what an implementation may define the behavior to be. The specification clearly distinguishes implementation-defined behavior from undefined behavior; conflating them would be a contradiction.

The specification also allows an implementation to provide extensions, which among other things may include additional library functions beyond those described in the standard. Such an implementation is still considered to be conforming. And the specification defines a conforming program to be a program that is acceptable to a conforming implementation.

So really, the only time it's hard to write useful C without provoking undefined behavior is if you're constraining yourself to the narrower definition of a "strictly conforming program." Real-world C enjoys permission to use implementation-defined behavior, which means that you can adopt other standards (such as POSIX) on top of the C standard that promote all sorts of stuff from "plain UB" to well-defined, as long as you're using a compiler that conforms with all of the standards you require.

/s/ Adam