 |
lua-l archive |
|
|
||
|
(also @Roberto) On 07/09/2021 03:44, Coda Highland wrote:
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. -- RobertoThe 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.")
That's exactly the remark I was going to make.I completely agree with Roberto that the sentence is confusing. And (I guess) especially for us non-native English speakers (Roberto and I, I mean), because, as you pointed out, it is grammatically incorrect. At least the first comma should be omitted.
As I get it, the UB(TM) is just a marker the standard applies to well described cases (it's tempting to say "well-defined") mentioned in the standard itself. If you like, you could call it "splork behavior" (for want of a less confusing term), if putting the word "undefined" in it causes confusion (as it does).
So the standard states that some, *exactly described*, cases are "splork", all the other cases one could imagine are "simply" plainly undefined (but not splork).
What I say is supported by the fact the cases of splork behavior can be enumerated exhaustively, as the article I pointed to demonstrates (if you dig into it you also find the "%#c" case, for example). In fact the state in the article that there are "just" ~200 splork cases, no more no less.
In other words, only the standard can say something is splork. If the standard is simply silent on some case, then it's not splork (but just plainly undefined, as any sane people not sitting in the C committee would say).
Note that some of those splork cases have quite a wide scope, whereas some other have very narrow meaning. So the fact they can be enumerated doesn't mean that the actual set of use cases is small.
BTW, from the same author, this is also interesting: https://blog.regehr.org/archives/213
[snip] /s/ Adam
-- Lorenzo