Re: Computer architects leaving Intel...

Michael S <already5chosen@yahoo.com> schrieb:

On Fri, 13 Sep 2024 21:39:39 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
>

Michael S <already5chosen@yahoo.com> schrieb:

On Fri, 13 Sep 2024 04:12:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

Michael S <already5chosen@yahoo.com> writes: 

 

struct {
 char x[8]
 int  y;
} bar;
bar.y = 0; bar.x[8] = 42;
>
IMHO, here behavior should be fully defined by implementation.
And in practice it is.  Just not in theory.   

 
Do you mean union rather than struct?  And do you mean bar.x[7]
rather than bar.x[8]?  Surely no one would expect that storing
into bar.x[8] should be well-defined behavior.
 
If the code were this
 
    union {
      char x[8];
      int  y;
    } bar;
    bar.y = 0;  bar.x[7] = 42;
 
and assuming sizeof(int) == 4, what is it that you think should
be defined by the C standard but is not?  And the same question
for a struct if that is what you meant. 

>
>
No, I mean struct and I mean 8.
And I mean that a typical implementation-defined behavior would be
bar.y==42 on LE machines and bar.y==42*2**24 on BE machines.
As it actually happens in reality with all production compilers. 

 
Ah, you want to re-introduce Fortran's storage association and
common blocks, but without the type safety.  Good idea, that.
That created *really* interesting bugs, and Real Programmers (TM)
have to have something that pays their salaries, right?
 
SCNR

>
What I wrote is how all production C compilers work today. So it
will add no new bugs. What I propose is to formally codify 50 y.o.
existing practice.

So was Fortran's misuse of COMMON Blocks.

And no, it's both much easier to follow than old FORTRAN common blocks

You want to allow array bounds violations and type punning rolled into
one?

I beg to differ that this is in any way easier, or better.

and has wider scope (applies to all storage classes, rather than just
to global).

You're correct, the potential for mischief is far greater.