[Coco] Found strangeness in C compiler (bug)

[Gene Heskett]

On Tuesday 21 May 2019 08:12:52 am Mathew Boytim via Coco wrote:

And I have to wonder why you, Walter, haven't mentioned using trig.l for 
the heavy math in your looping construction. I have never written 
anything needing math without using trig.l as one of the library's to 
search thru, and what I wrote has always behaved itself.  Trig.l is or 
should be in the nitros9 repo. Should, I can't find it there. checking 
toolshed.  Humm, there is a trig.a in toolshed but I've no clue is a 
dissed version of the built trig.c. But you can get the original, hand 
optimized by me, from

 <http://geneslinuxbox.net:6309/gene/Genes-os9-stf/triglib.lzh>

This was originally published by an deathly ill Portuguese teenager who 
placed it in the public domain, where it was originally printed on a 
dot-matrix printer at Falsoft, forever confusing a 1 with an l, then 
published in the Rainbow. I figure that out, then built it by passing 
an -a to cc, then hand optimized C's biggest time sink, bit shifts by 
shifting the first 8 bits out of in in favor of a register swap, took 8 
passes thru a one bit shift back out of it with some hand editing, then 
finished the compile.

Why its not in toolshed is beyond me, I've thrown the book at it, and its 
given me the correct answers everytime.


>  I agree the result is undefined.  This is what gcc has to say
>  main.c:7:4: warning: operation on ‘da’ may be undefined
> [-Wsequence-point] *da++ = *dN++ * v - *da; // this is correct as the
> increment should happen after the assignment  ~~^~
>
> The standard doesn't say when the pointer is incremented, it only says
> where the result will be stored so you can't say "the increment will
> happen after the assignment".  I have to agree that the behavior is
> not what I would expect but undefined is undefined.  Bottom line is
> that you can't do that and expect it to be predictable. Matt
>
>
>
>     On Tuesday, May 21, 2019, 2:06:14 AM EDT, Mark McDougall
> <msmcdoug at iinet.net.au> wrote:
>
>  On 21/05/2019 3:32 pm, Walter Zambotti wrote:
> > *da = *dN++ * v - *da++;  // this is wrong as the expression on the
> > right increments da before it is assigns the value to where da
> > points.
>
> I think you'll find this behaviour is undefined by the standard, which
> is why you have inconsistent results depending on type.
>
> It's not something I'd code that way in any case. I think your "work
> around" is better (more readable/maintainable) code.
>
> Regards,
>
> ---8<------8<------8<------8<------8<------8<------8<------8<------8<-
>-----8<---
>
> 2) Between the previous and next sequence point, the prior value of a
> scalar object that is modified by the evaluation of the expression,
> must be accessed only to determine the value to be stored. If it is
> accessed in any other way, the behavior is undefined.
>
> cout << i << i++; // undefined behavior (until C++17)
> a[i] = i++; // undefined behavior (until C++17)
>
>
>
> --
> Mark McDougall
> <http://retroports.blogspot.com.au>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>