Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: I think references should have been const by default
Date: Fri, 29 Oct 2021 06:41:33 -0700
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <86o878dk36.fsf@linuxsc.com>
References: <skqtfl$17n5$1@gioia.aioe.org> <skr2r3$81j$1@dont-email.me> <skrd0t$1p75$1@gioia.aioe.org> <skrh21$ksj$1@dont-email.me> <skrqki$obd$1@gioia.aioe.org> <skrs1e$co2$1@dont-email.me> <sktq8m$7ht$1@dont-email.me> <skuj0p$t60$1@dont-email.me> <sl0nmu$bn3$1@dont-email.me> <sl0qcj$sub$1@dont-email.me> <sl1e73$sl7$1@dont-email.me> <sl5pdi$4au$1@gioia.aioe.org> <sl5ug4$qov$1@gioia.aioe.org> <sl6ecq$11uu$1@gioia.aioe.org> <sl6go4$pjq$1@dont-email.me> <sl6k3n$e8m$1@gioia.aioe.org> <8735op2cv0.fsf@nosuchdomain.example.com> <sl961t$qs4$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="b7f56eff5ad6c7d9130605d054ce58ef"; logging-data="5278"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mPeCxQYJNzDix7ISPcXgd8qJiMhxSSxs="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:wuwPzI1k2VGZOkvb+IVeXpQQ05w= sha1:6/mxohHUSUBkKLmN5rknMtG5IHU=
Xref: csiph.com comp.lang.c++:82176

Manfred <noname@add.invalid> writes:

> On 10/25/2021 8:11 PM, Keith Thompson wrote:
>
>> Manfred <noname@add.invalid> writes:
>>
>>> On 10/25/2021 4:59 PM, James Kuyper wrote:
>>>
>>>> On 10/25/21 10:19 AM, RacingRabbit@watershipdown.co.uk wrote:
>>>
>>> <snip>
>>>
>>>>> No idea what UB means, but what'll happen is it'll crash
>>>>> immediately so you'll soon find out.
>>>>
>>>> UB means "Undefined Behavior", a technical term from the C
>>>> standard which does NOT mean "behavior for which there is no
>>>> definition".  It means "behavior, upon use of a nonportable or
>>>> erroneous program construct or of erroneous data, for which this
>>>> document imposes no requirements" (3.4.3).  Note that "this
>>>> document" refers to the C standard;  other documents (such as
>>>> compiler documentation or ABI standards) might define the
>>>> behavior, without changing the fact that is qualifies as
>>>> "undefined behavior" as far as the C standard is concerned.
>>>
>>> Thanks for the quote, it made me compare it with the definition of
>>> UB in the C++ standard, which simply states "behavior for which
>>> this International Standard imposes no requirements".
>>>
>>> The lack of the sentence "upon use of a nonportable or erroneous
>>> program construct or of erroneous data" actually relegates the
>>> language at the mercy of language lawyers, and led to the UB bloat
>>> that affects C++ nowadays.
>>
>> [...]
>>
>> I don't see how the omission of "upon use of a nonportable or
>> erroneous program construct or of erroneous data" in the C++
>> standard makes any real difference.
>
> It depends on the reader:  whether it is some sort of text
> processing machine, a language lawyer or a human being.
>
>> C definition, all standard editions:
>>      behavior, upon use of a nonportable or erroneous program
>>      construct or of erroneous data, for which this International
>>      Standard imposes no requirements
>>
>> C++ definition, before C++11:
>>      behavior, such as might arise upon use of an erroneous program
>>      construct or erroneous data, for which this International
>>      Standard imposes no requirement
>>
>> C++ definition, C++11 and later:
>>      behavior for which this International Standard imposes no
>>      requirements
>>
>> In all cases, "undefined behavior" is determined either by an
>> explicit statement or by the omission of any definition of the
>> behavior (or, in C, by violation of a "shall" outside a
>> constraint).
>
> For a human being, the additional sentence makes a difference,
> simply because it is there:  it means that the writer had a reason
> to write it, and such writer's intent is part of the message that
> matters to a human reader.
>
> More specifically:
>
> In C, the additional sentence actually poses a distinctive
> characterization of the code that qualifies for undefined behavior,
> i.e. "nonportable or erroneus" code, which is something else than
> saying "anything that is not explicitly defined here".  Now, the
> problem is that the C definition actually redirects to a definition
> of "nonportable" and (more relevantly) "erroneous", so a machine
> reader might trigger an "undefined reference" error and stop
> parsing.  A language lawyer might interpret the wording as implying
> that anything that is not explicitly defined is considered
> "nonportable" or "erroneous", but that's an interpretation which is
> still to be proven to hold in court, since the other party's lawyer
> might interpret the same wording as UB being <<anything that is
> "nonportable" or "erroneous" /and/ is not covered by this
> standard's requirements>>
>
> [...]

Thank you for injecting a note of sanity into a discussion of
what text in the C and C++ standards means.