Re: Computer architects leaving Intel...

Michael S <already5chosen@yahoo.com> writes:

On Thu, 12 Sep 2024 03:12:11 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>

BGB <cr88192@gmail.com> writes:
>
[...]
>

Would be nice, say, if there were semi-standard compiler macros for
various things:
  Endianess (macros exist, typically compiler specific);
    And, apparently GCC and Clang can't agree on which strategy to
use.  Whether or not the target/compiler allows misaligned memory
access;  If set, one may use misaligned access.
  Whether or not memory uses a single address space;
    If set, all pointer comparisons are allowed.
>
[elaborations on the above]

>
I suppose it's natural for hardware-type folks to want features
like this to be part of standard C.  In a sense what is being
asked is to make C a high-level assembly language.  But that's
not what C is.  Nor should it be.

>
Why not?

Because it's not needed, and would make things worse rather
than better.  The result would be a bigger language but not
a better language.

I don't see practical need for all those UBs apart from buffer
overflow.  More so, I don't see the need for UB in certain
limited classes of buffer overflows.

Eliminating undefined behavior is not what's being asked for.
These two questions are not the same.

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.