Groups | Search | Server Info | Login | Register
Groups > comp.lang.c > #391438
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: int a = a |
| Date | 2025-03-20 12:46 -0700 |
| Organization | None to speak of |
| Message-ID | <87msdfscxj.fsf@nosuchdomain.example.com> (permalink) |
| References | (6 earlier) <vrelvn$12ddq$1@dont-email.me> <87sen8u5d5.fsf@nosuchdomain.example.com> <86zfhgni2a.fsf@linuxsc.com> <87cyect356.fsf@nosuchdomain.example.com> <vrhbsf$3e7sn$4@dont-email.me> |
David Brown <david.brown@hesbynett.no> writes:
> On 20/03/2025 11:20, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> The "could have been declared with the register storage class"
>>>> seems quite odd. And in fact it is quite odd.
>>>
>>> I don't have the same reaction. The point of this phrase is that
>>> undefined behavior occurs only for variables that don't have
>>> their address taken. The phrase used describes that nicely.
>>> Any questions related to "registerness" can be ignored, because
>>> 'register' in C really has nothing to do with hardware registers,
>>> despite the name.
>> DR 338 is explicitly motivated by an IA-64 feature that applies only
>> to
>> CPU registers. An object whose address is taken can't be stored (only)
>> in a register, so it can't have a NaT representation.
>> The phrase used is "could have been declared with register storage
>> class
>> (never had its address taken)". Surely "never had its address taken"
>> would have been clear enough if CPU registers weren't a big part of the
>> motivation.
>
> I too think the phrasing is a bit odd.
>
> Just because a variable's address is taken, does not mean it cannot be
> put in a cpu register by the compiler. If the variable is not
> accessed in a way that actually requires putting it in memory, then
> the compiler can put it in a cpu register (or otherwise optimise it).
> So simply taking the address of a variable on IA-64 does not mean it
> cannot be in a register, and thus does not necessarily mean it cannot
> be NaT. Taking the address of a variable means the variable cannot be
> declared "register", but it does not mean it cannot be /in/ a
> register.
Sure, any variable that's stored in memory can be mirrored by holding
its value in a register.
int n = 42; // Assume n is assigned a memory address
printf("n+1=%d n+2=%d\n", n+1, n+2);
A compiler could plausibly store the value of n in a register before
computing n+1, and then reuse the register value to compute n+2.
My understanding is that IA-64 NaT (Not a Thing) representations
exist only for registers, and the NaT bit should be cleared when
a value is stored in the register.
The odd wording in the standard allows an IA-64 C compiler to
take advantage of NaT representations for their intended purpose.
It might impose some minor constraints on what machine code can be
generated, but *most* of the cases where a NaT could be accessed
are undefined behavior in C.
> It seems very strange to me that this is UB:
>
> int foo1(void) {
> int x;
>
> return x;
> }
>
> while this is not :
>
> int foo2(void) {
> int x;
>
> int * p = &x;
>
> return x;
> }
>
> (Unfortunately, godbolt.org doesn't seem to have a gcc IA-64 compiler
> in its list.)
>
> It strikes me that it would have been far simpler for the standard
> simply to say that using the value of an uninitialised and unassigned
> variable is undefined behaviour.
In C90, it was. C99 changed that, making the behavior defined if the
representation is not a trap representation.
For C99, a conforming IA-64 C compiler would have had to go out of its
way to avoid accessing NaT representations. For example, if you wrote
{
int n;
n;
}
the most straightforward IA-64 code would store n in a register and
not initialize it, resulting in a trap when the register is read.
A compiler might have to generate code to store an arbitrary value
in the register to void the trap.
I'm undecided on whether reading the value of an uninitialized
automatic object *should* be undefined behavior, but given that
it isn't, the C11 committee made the smallest possible change to
cater to IA-64 semantics.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Bart's Language bart <bc@freeuk.com> - 2025-03-17 23:51 +0000
Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 12:17 +0000
Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 13:54 +0000
Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 15:10 +0000
Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 15:45 +0000
Re: Bart's Language David Brown <david.brown@hesbynett.no> - 2025-03-18 17:31 +0100
int a = a (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-18 18:04 +0000
Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 19:36 +0100
Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-18 19:11 +0000
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 15:56 +0100
Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:38 +0000
Re: int a = a (Was: Bart's Language) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-19 14:29 -0700
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 09:39 +0100
Re: int a = a (Was: Bart's Language) bart <bc@freeuk.com> - 2025-03-20 11:59 +0000
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:46 +0100
Re: int a = a (Was: Bart's Language) wij <wyniijj5@gmail.com> - 2025-03-20 23:13 +0800
Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:02 -0700
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:57 +0100
Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-19 17:07 +0000
Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 13:34 -0700
Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:54 -0700
Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 03:20 -0700
Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 16:22 +0100
Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:46 -0700
Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 10:44 +0100
Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 12:23 -0700
Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 21:46 +0100
Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 13:59 -0700
Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 15:37 -0700
Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 15:42 +0100
Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 19:37 +0000
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-18 20:51 +0100
Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 23:27 +0100
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:40 +0100
Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 23:52 -0700
Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 01:55 -0700
Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:43 +0100
Re: int a = a (Was: Bart's Language) Rosario19 <Ros@invalid.invalid> - 2025-03-19 13:23 +0100
Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 01:32 -0700
Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:55 +0000
Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:22 -0700
Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 14:37 +0000
Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 11:41 -0400
Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 16:52 +0000
Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 20:12 -0400
By definition... (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-23 17:20 +0000
Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 22:19 +0000
Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:38 +0000
Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 23:45 +0000
Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:56 +0000
Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 17:47 +0000
Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 07:12 -0700
Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:33 +0000
csiph-web