Liste des Groupes | Revenir à c arch |
On Thu, 12 Sep 2024 16:34:31 +0200No, it should not.
David Brown <david.brown@hesbynett.no> wrote:
On 12/09/2024 13:29, Michael S wrote:bar.x[8] = 42 should be defined to be the same asOn 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?
char tmp = 42
memcpy(&bar.y, &tmp, sizeof(tmp));
Les messages affichés proviennent d'usenet.