Re: what is defined, was for or against equality

Spiros Bousbouras <spibou@gmail.com>
Sat, 8 Jan 2022 22:28:00 -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)
Re: what is defined, was for or against equality david.brown@hesbynett.no (David Brown) (2022-01-11)
[5 later articles]
| List of all articles for this month |

From: Spiros Bousbouras <spibou@gmail.com>
Newsgroups: comp.compilers
Date: Sat, 8 Jan 2022 22:28:00 -0000 (UTC)
Organization: A noiseless patient Spider
References: <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> 22-01-016 22-01-018 22-01-020 22-01-027 22-01-032
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="24246"; mail-complaints-to="abuse@iecc.com"
Keywords: C, standards
Posted-Date: 08 Jan 2022 17:58:29 EST
In-Reply-To: 22-01-032

On Sat, 8 Jan 2022 09:31:06 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
> Spiros Bousbouras <spibou@gmail.com> schrieb:
> > On Thu, 6 Jan 2022 16:43:05 -0000 (UTC)
> > Thomas Koenig <tkoenig@netcologne.de> wrote:
> >> 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


The C standard is in no position to say that some programme is in
error. This would require near omniscience from the standard
writers.


> #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.


The only difference I see between the two is that the first is defined
by POSIX and the second is not. According to POSIX the first is required
to print something on stdout. I cannot imagine any extension which
would make the second programme do something useful and a conforming
implementation may well compile it as essentially a no-op.


But with something like


int main(voidd) {
        int *p = 0 ;
        *p = 42 ;
        .... do other stuff ...
        return 0 ;
}


the C standard allows for a conforming implementation to do something
useful like perhaps store 42 to address 0.


> 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 :-)


No , it most definitely does not say that nor could it possibly say
that.


Post a followup to this message

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