Re: what is defined, was for or against equality

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.


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


A front end translates the source to an abstract syntax tree (which
you can view with gfortran with -fdump-fortran-original) and from
that into an intermediate representation (which you can view with
gfortran, or with gcc in general, with -fdump-tree-original).
This intermediate representation is then optimized, in
an architecture-independent way (usually using SSA) and then
translated into assembler or directly to object code using a
"back end", of which many compilers also have several.


An example: The program


    print *,"Hello, world"
end


is translated into (code only)


    WRITE UNIT=6 FMT=-1
    TRANSFER 'Hello, world'
    DT_END


and then, in the intermediate representation.


MAIN__ ()
{
    {
        struct __st_parameter_dt dt_parm.0;


        dt_parm.0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
        dt_parm.0.common.line = 2;
        dt_parm.0.common.flags = 128;
        dt_parm.0.common.unit = 6;
        _gfortran_st_write (&dt_parm.0);
        _gfortran_transfer_character_write (&dt_parm.0, &"Hello, world"[1]{lb: 1 sz: 1}, 12);
        _gfortran_st_write_done (&dt_parm.0);
    }
}


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.


And there are certainly differences in the code that the front
ends handle to the middle end, so saying that there is "no
difference in the implementations" is not correct.


>> 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
>>
>> #include <unistd.h>
>> #include <string.h>
>>
>> int main()
>> {
>> char a[] = "Hello, world!\n";
>> write (1, a, strlen(a));
>> return 0;
>> }
>>
>
> 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.






> It just means it is defined
> elsewhere, not in the C standards.


Nope, see above.


(If you replaced every occurence of "undefined behavior" in the C
standard with "WRTLPFMFT behavior" and "the behavior is undefined"
with "the behavior is WRTLPFMFT", the meaning of the standard
would not change.)
[It seems like nitpicking here. Yes, the C and POSIX standards are
different things, but we all know how common it is to use them
together. -John]

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