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) |
[9 later articles] |
From: | Thomas Koenig <tkoenig@netcologne.de> |
Newsgroups: | comp.compilers |
Date: | Thu, 6 Jan 2022 16:43:05 -0000 (UTC) |
Organization: | news.netcologne.de |
References: | <17d70d74-1cf1-cc41-6b38-c0b307aeb35a@gkc.org.uk> 22-01-016 22-01-018 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="46644"; mail-complaints-to="abuse@iecc.com" |
Keywords: | design, standards |
Posted-Date: | 06 Jan 2022 13:11:20 EST |
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.
[...]
> The real challenge from big languages and big standard libraries is not
> /writing/ code, it is /reading/ it. It doesn't really matter if a C
> programmer, when writing some code, does not know what the syntax "void
> foo(int a[static 10]);" means. (Most C programmers don't know it, and
> never miss it.) But it can be a problem if they have to read and
> understand code that uses something they don't know.
Agreed.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.