Re: what is defined, was for or against equality

On 06/01/2022 17:43, Thomas Koenig 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.


C has basically the same concept.


(IIRC, C++ as a few constraints such as the "one definition rule" that
where the standard says no diagnostics are necessary, because
identifying the error would mean the compiler has to see multiple
translation units at once. Compilers often diagnose these if they have
some kind of link-time optimisation or program-at-once mode.)


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


That is the same in C. From 4.2 "Conformance" :


"""
If a “shall” or “shall not” requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined.
Undefined behavior is otherwise indicated in this International Standard
by the words “undefined behavior” or by the omission of any explicit
definition of behavior. There is no difference in emphasis among these
three; they all describe “behavior that is undefined”.
"""


The only difference I see from what you describe of Fortran (I have not
read any Fortran standards) is that the C standards also note that
behaviour that is not defined in the standards is undefined behaviour as
far as the standards are concerned. That is a tautology, of course, and
applies equally to Fortran and any other language.




It is quite possible that the details of which behaviours are defined or
not varies between the languages - things like division by 0,
out-of-bounds array access, etc., may be different. As I understand it,
passing aliased pointers or array references as different parameters to
the same function can lead to undefined behaviour in Fortran, whereas it
is defined in C (unless you use "restrict").




> [...]
>
>> 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.