Re: storing an integer in a double precision

steve <kargls@xxxxxxxxxxx> wrote:

On May 6, 8:54 am, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:

The compiler might do an increment and then test instead of computing
the trip count. The last increment would then overflow - well what was
supposed to be the last increment. That seems quite plausible to me.

Then the 'compiler' is not a Fortran compiler as 8.1.6.4.2
clearly states that the iteration count is tested for loop
termination,

I disagree that the standard specifies implementation at that level. The
standard just describes what the effect has to be. Other methods that
get the sam effect are allowed. Now you will probably note, quite
reasonably, that the other methods don't get the same effect. But the
differences are only when you hit overflow, which puts it outside the
guarantees of the standard.

You also seem to have elided my comment that

Also note that the value of i after the DO loop terminates should be
huge(i)+1, which puts you in "anything can happen" territory.

I think that is very pertinent, which is why I said it. Because of that,
nothing in the stanard basically guarantees anything for the program.
No, you don't get to limit the ways in which that could possibly cause
problems. The program is nonconforming and the compiler is allowed to do
all kinds of strange or not-so-strange things. It isn't required to
operate as otherwise expected up to that point. For example, a compiler
could, in principle, notice the problem and refuse to compile the code.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle
.

Relevant Pages

  • Re: HardBound and SoftBound
    ... The C standard has never defined C as it is ... was "C doesn't specify what happens on overflow". ... This is the same nonsense - the compiler doesn't control the ... string, ...
    (comp.arch)
  • Re: Is tab[x++] = val undefined?
    ... increment the value of x ... As it is the only write to x that is to do to x it does not matter ... Which of the steps is done first is left to the compiler as freedom to ... The standard describes that rules unabigous. ...
    (comp.std.c)
  • Re: A Type Conversion Question
    ... Kevin Bracey writes: ... So the compiler is free to do what it wants. ... > However, for unsigned arithmetic, the standard does require results to be ... nearly all implementations document signed arithmetic overflow as being ...
    (comp.lang.c)
  • (part 25) Han from China answers your C questions
    ... be able to 'explain' it in terms of the famous C standard. ... sequence points, in some indeterminate order. ... increment p. ... And it allows the compiler to generate code that will evaluate ...
    (comp.lang.c)
  • Re: HardBound and SoftBound
    ... The C standard has never defined C as it is ... but the GCC team thinks differently. ... was "C doesn't specify what happens on overflow". ... These people don't understand that a compiler is a mean to an end - writing ...
    (comp.arch)