Re: what is defined, was for or against equality

Spiros Bousbouras <spibou@gmail.com> schrieb:
> 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.


A standard (or other specification document) is certainly able to
state that some construct is in error. To grab an often-quoted
example:


J3/18-007r1, the Fortran 2018 interpretation documents, states in
subclause 9.5.3, "Array elements and array sections",


# The value of a subscript in an array element shall be within the
# bounds for its dimension.


No omnicience required to write or understand that sentence.


This puts the burden on the programmer. The compiler might catch
such an error error and abort the program, or other unpredictable
things such as overwriting an unrelated variable might also happen.


Reading a language standard can be hard. Quite often, information
is scattered throughout the text and needs to be pieced together
to find the necessary information, especially definition of terms
which are crucial to understanding. Most programmers do do not
read standards (at least final committee drafts can usually be
found these days on the Internet), but compiler writers should at
least be familiar with what they are implementing.


Programmers often rely on books, but these can also get things wrong.


Because programmers are human, they also can get ticked off when being
told that a construct they have used for years has been illegal
for decades :-|


Having a good standard is crucial to being able to write good compilers.

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