Re: what is defined, was for or against equality

On 10/01/2022 13:04, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>> The big question here, is why do you think Fortran is any different? In
>> theory, there isn't a difference - nothing you have said here convinces
>> me that there is any fundamental difference between Fortran and C in
>> regards to undefined behaviour.
>
> I am not sure how to better explain it. I will try a bit, but
> this will be my last reply to you in this thread. We seem to have
> a fundamental difference in our understanding, and seem to be
> unable to resolve it.
>


Fair enough. Maybe in a future discussion, one of us will have an
"Aha!" moment and understand the other's viewpoint, and progress will be
made - until then, there's no point in going around in circles. I'll
snip bits of your post here, and try to minimise new points (unless I
get that "Aha!") - but be sure I am reading and appreciating your entire
post.


>> (And there's no difference in the
>> implementations - the most commonly used Fortran compilers also handle
>> C, C++, and perhaps other languages.)
>
> Sort of.
>
> At the risk of boring most readers of this group, a very short, but
> (hopefully) pertinent introduction of how modern compilers work:
>
>
> There is no compiler (if you mean a single binary) that handles both
> C and Fortran. They are separate front ends to common middle
> and back ends.


Yes. But it is the middle end that handles most of the optimisations,
including those based on undefined behaviour. The front end determines
whether code can have undefined behaviour and in what circumstances.


>> C does not have a "write" function in the standard library. So the
>> behaviour of "write" is not defined by the C standards - but that does
>> not mean the behaviour is undefined.
>
> When interpreting at a language standard, you _must_ follow the
> definitions in the standards if they exist, you cannot use everyday
> interpretations.
>
> Subclause 3.4.3 (N2596) defines
>
> # undefined behavior
>
> # behavior, upon use of a nonportable or erroneous program
> # construct or of erroneous data, for which this document imposes
> # no requirements
>
> write() is nonportable and the C standard imposes no requirements
> on it. Therefore, the program above invokes undefined behavior.


No. (As always, this is based on my interpretation of the standards -
consider everything to have "IMHO" attached.) The implementation of
"write" is outside the scope of the standards, and is therefore
undefined as far as the standards are concerned. That does not make it
undefined behaviour in the program - it just means the standards don't
say what "write" should do.

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