Liste des Groupes | Revenir à c arch |
On Sun, 15 Sep 2024 12:19:02 -0000 (UTC)It is.
Waldek Hebisch <antispam@fricas.org> wrote:
Michael S <already5chosen@yahoo.com> wrote:Padding is another thing that should be Implementation Defined.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'.
I.e. compiler should provide complete documentation of its paddingThey do. Or, they should. Often they are lazy and say "defined by the platform ABI". Really, it is only the alignments that are needed.
algorithms.
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.
Les messages affichés proviennent d'usenet.