Re: what is defined, was for or against equality

Thomas Koenig <tkoenig@netcologne.de>
Sat, 8 Jan 2022 09:31:06 -0000 (UTC)

          From comp.compilers

Related articles
Re: what is defined, was for or against equality tkoenig@netcologne.de (Thomas Koenig) (2022-01-06)
Re: what is defined, was for or against equality david.brown@hesbynett.no (David Brown) (2022-01-07)
Re: what is defined, was for or against equality spibou@gmail.com (Spiros Bousbouras) (2022-01-07)
Re: what is defined, was for or against equality tkoenig@netcologne.de (Thomas Koenig) (2022-01-08)
Re: what is defined, was for or against equality spibou@gmail.com (Spiros Bousbouras) (2022-01-08)
Re: what is defined, was for or against equality tkoenig@netcologne.de (Thomas Koenig) (2022-01-09)
Re: what is defined, was for or against equality spibou@gmail.com (Spiros Bousbouras) (2022-01-09)
Re: what is defined, was for or against equality david.brown@hesbynett.no (David Brown) (2022-01-09)
Re: what is defined, was for or against equality tkoenig@netcologne.de (Thomas Koenig) (2022-01-10)
Re: what is defined, was for or against equality gah4@u.washington.edu (gah4) (2022-01-10)
[6 later articles]
| List of all articles for this month |

From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.compilers
Date: Sat, 8 Jan 2022 09:31:06 -0000 (UTC)
Organization: news.netcologne.de
References: <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> 22-01-016 22-01-018 22-01-020 22-01-027
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="51668"; mail-complaints-to="abuse@iecc.com"
Keywords: standards, optimize
Posted-Date: 08 Jan 2022 13:11:52 EST

Spiros Bousbouras <spibou@gmail.com> schrieb:
> On Thu, 6 Jan 2022 16:43:05 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>> > There is no need to memorize undefined behaviours for a language -
>> > indeed, such a thing is impossible since everything not defined by a
>> > language standard is, by definition, undefined behaviour. (C and C++
>> > are not special here - the unusual thing is just that their standards
>> > say this explicitly.)
>>
>> This is a rather C-centric view of things. The Fortran standard
>> uses a different model.
>>
>> There are constraints, which are numbered. Any violation of such
>> a constraint needs to be reported by the compiler ("processor",
>> in Fortran parlance). If it fails to do so, this is a bug in
>> the compiler.
>>
>> There are also phrases which have "shall" or "shall not". If this
>> is violated, this is an error in the program. Catching such a
>> violation is a good thing from quality of implementation standpoint,
>> but is not required. Many run-time errors such as array overruns
>> fall into this category.
>
> This seems to me exactly like the C model. What difference do you see ?


First, I see a difference in result. Highly intelligent and
knowledgable people argue vehemently if a program should be able
to use undefined behavior or not, and lot of vitriol is directed
against compiler writers who use the assumption that undefined
behavior cannot happen in their compilers for optimization,
especially if it turns out that existing code was broken and no
longer works after a compiler upgrade (Just read a few of Linus
Torvald's comments on that matter).


I see C conflating two separate concepts: Programm errors and
behavior that is outside the standard. "Undefined behavior is
always a programming error" does not work; that would make


#include <unistd.h>
#include <string.h>


int main()
{
    char a[] = "Hello, world!\n";
    write (1, a, strlen(a));
    return 0;
}


not more and not less erroneous than


int main()
{
    int *p = 0;
    *p = 42;
}


whereas I would argue that there is an important difference between
the two.


If the C standard replaced "the behavior is undefined" with "the
program is in error, and the subsequent behavior is undefined"
or something along those lines, the discussion would be much
muted.


(Somebody may point out to me that this what the standard is
actually saying. If so, that would sort of reinforce my argument
that it should be clearer :-)


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.