Re: Computer architects leaving Intel...

On Thu, 12 Sep 2024 16:34:31 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 12/09/2024 13:29, Michael S wrote:

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. 

 

 
I fully agree that C is not, and should not be seen as, a "high-level
assembly language".  But it is a language that is very useful to
"hardware-type folks", and there are a few things that could make it
easier to write more portable code if they were standardised.  As it
is, we just have to accept that some things are not portable.
 

Why not?
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.
 
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.
 

 
And how should that be defined?

bar.x[8] = 42 should be defined to be the same as
  char tmp = 42
  memcpy(&bar.y, &tmp, sizeof(tmp));