Re: Computer architects leaving Intel...

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?  And what is its "practical" definition?   My preference would be a hard compile-time error, but specifying that in the standards would force compilers to do more analysis and checking than the standards can reasonably enforce.
clang can warn on this - I am disappointed to see that gcc does not.