Re: Computer architects leaving Intel...

On 2024-09-15 12:09 p.m., David Brown wrote:

On 15/09/2024 14:40, Michael S wrote:

On Sun, 15 Sep 2024 12:19:02 -0000 (UTC)
Waldek Hebisch <antispam@fricas.org> wrote:
>

Michael S <already5chosen@yahoo.com> wrote:

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:

>
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));

>
That has two drawbacks: minor one that you need to know that
there are no padding between 'x' and 'y'.

>
Padding is another thing that should be Implementation Defined.

 It is.
 

I.e. compiler should provide complete documentation of its padding
algorithms.

 They do.  Or, they should.  Often they are lazy and say "defined by the platform ABI".  Really, it is only the alignments that are needed.
 C defines the minimum padding between members in a struct - you get the padding needed to ensure that members are correctly aligned.  I don't think the C standards disallow additional padding, but it would be an extraordinarily strange implementation if there were anything more than this minimum padding.
 But I certainly wouldn't mind if the standards dictated this minimum padding, and then there would be nothing left to the implementation other than alignments.
 

In addition, some padding-related things can be defined by Standard
itself. Not in this particular case, but, for example, it could be
defined that when field of one integer type is immediately followed by
another field of integer type with the same or narrower width then
there should be no padding in-between.
>

 

What about bit-fields in a struct? I believe they are usually packed. In case its for something like an I/O device.