Re: Append to screen IO

Richard Maine wrote:
Ben Hetland <ben.a.hetland@xxxxxxxxx> wrote:
Typical way to solve conflicts and get matters through the decision
process. Apparently no problem seems to exist anymore if you stick your
head in the sand ...

I would say that was a miscategorization of this issue. You are talking
here about what happens when the code has an error.

No, I was not. I was referring to the case when the code was correct but
exceeded some compiler-imposed limit. I.e. code which doesn't violate
any part of the standard, and could also in princible have been compiled
as expected by another standard-compliant compiler.


In this case, the
error is exceeding an implementation limit.

Well, is that an error?
If so, how is one supposed to know when one is about to commit such a
sin, when neither the standard nor the compiler implementation will
identify it as such?

Follow-up question: If such an error has been commited, who is the
"guilty" one of committing it? The original programmer who found it to
violate no Fortran standard, and whose compiler happily did not have a
limitation that (s)he has exceeded? Or is it the down-stream unlucky
programmer who inherited the code with hundreds of such usages, but
whose compiler unfortunately has a stricter limit to its things?



Note first that not until f90 did the
standard say anything at all about the behavior of errors at
all. It only addressed what happened with correct programs.

OK, that's a good point indeed!
But it means that the programmer has to be a damn good one to be sure
that the code is correct, if only regarding source code correctness
(ignoring logical, algorithmic and other non-language issues). Hmm...
thinking about it, this seems to be the C philosofy "trust the
programmer" at its most extreme!


You will never be able to get a system that diagnoses absolutely every
possible failure. Don't forget to include system failures such as
catching on fire (which does happen; I've seen it).

That was not expected either... ;-)


The standard is not an appropriate place to solve every problem in the
world - not even every Fortran related problem. There actually is a role
for such things as competition. I might say that those who expect that
the standard will solve every problem they have might themselves have
their head in the sand to the extent that they are unable to see the
real world out there.

Sure, and it's perhaps a better measure of evaluating potentially
competing compiler vendors.

But I know that a lot of "programmers" (e.g. Fortran coders in
particular) actually rely on their compiler to tell them what's standard
or not, or if they don't care too much about the standard, to tell them
what's possible to compile. Of course they experience the usual hazzle
whenever they change compiler...

--
-+-Ben-+-
.

Relevant Pages

  • Re: Bugs at my web site
    ... >> I don't think it's being maintained now, but given that Fortran 77 isn't ... >what might prove fatal with a new compiler. ... >that I think they are good traditional fortran, whatever some standard might ... guess at heart I'm still a scientist rather than a Real Programmer :-) ...
    (comp.lang.fortran)
  • Re: I wasnt expected that !
    ... > Standard version of the software. ... But Borland compiler never behaved so badly ... You guys are lucky to have optimizing version of the compiler ... I wouldn't expect the casual programmer to ...
    (microsoft.public.dotnet.languages.vc)
  • Re: (long) An AES implementation for 32-bit platforms
    ... > because the author implied that it was, in referring to the C standard. ... >> wonder about your deduction procedure. ... Would it be C for a programmer that uses a C compiler ...
    (sci.crypt)
  • Re: Read problem
    ... The word "undefined" is never a limitation on the compiler. ... limiting the programmer are almost exactly the opposite. ... When the standard says that a variable becomes undefined, ... the compiler could certainly set the values to zero if they were ...
    (comp.lang.fortran)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)