Liste des Groupes | Revenir à c arch |
On Sat, 14 Sep 2024 20:14:23 -0000 (UTC)Contrary to your imagination - compilers have /never/ followed your proposed semantics. The oldest gcc version I found on godbolt.org is 3.4.6 from 2006, and given:
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:Yes, exactly.On Fri, 13 Sep 2024 21:39:39 -0000 (UTC)>
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:>On Fri, 13 Sep 2024 04:12:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:>>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.
Do you mean union rather than struct? And do you mean bar.x[7]
rather than bar.x[8]? Surely no one would expect that storing
into bar.x[8] should be well-defined behavior.
>
If the code were this
>
union {
char x[8];
int y;
} bar;
bar.y = 0; bar.x[7] = 42;
>
and assuming sizeof(int) == 4, what is it that you think should
be defined by the C standard but is not? And the same question
for a struct if that is what you meant.
>
No, I mean struct and I mean 8.
And I mean that a typical implementation-defined behavior would
be bar.y==42 on LE machines and bar.y==42*2**24 on BE machines.
As it actually happens in reality with all production compilers.
Ah, you want to re-introduce Fortran's storage association and
common blocks, but without the type safety. Good idea, that.
That created *really* interesting bugs, and Real Programmers (TM)
have to have something that pays their salaries, right?
>
SCNR
What I wrote is how all production C compilers work today. So it
will add no new bugs.
Maybe I should be a little bit more precise in why I think this
is an extemely bad idea.
>
struct {
char x[8]
int y;
} bar;
>
Assume
>
bar.y = 1234;
bar.x[i] = 42; // The compiler does not know i
// Do something with bar.y
>
The compiler should then treat the access to bar.x[i] as if bar.y
was clobbered by the assignment statement, and reload bar.y if
it was kept in a register? That is the semantics you propose.
>
Well, buggy according to your hypothetical semantics. Not buggy according to the way C has always worked, and the way C compilers generate code.So, either bar.y is treated as if it was volatile, or hard-to-detectNo, semantics is that compiler has to reload bar.y if it keeps it in
bugs would appear because, with optimization, the assignment would
sometimes change the value of bar.y and sometimes not.
register. Optimizer that does anything else is buggy.
Les messages affichés proviennent d'usenet.