Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: int a = a (Was: Bart's Language)
Date: Thu, 20 Mar 2025 23:13:34 +0800
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <9b5f3e86dd67128bb6612523ae17a7368b97284a.camel@gmail.com>
References: <vracit$178ka$1@dont-email.me>
	 <vrc2d5$1jjrf$1@paganini.bofh.team> <vrc4eb$2p28t$1@dont-email.me>
	 <vrc75b$2r4lt$1@dont-email.me> <vrccjb$b3m6$1@news.xmission.com>
	 <vrcef2$33076$1@dont-email.me> <vrelvn$12ddq$1@dont-email.me>
	 <aqCCP.590465$SZca.348513@fx13.iad> <vrfd0i$1n2ke$1@dont-email.me>
	 <vrgk82$2qpu6$1@dont-email.me> <vrgvue$35029$1@dont-email.me>
	 <vrh9o9$3e7sn$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Thu, 20 Mar 2025 16:13:36 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0d039cf101f5ca85a9d7be2c9a676daf";
	logging-data="3611499"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18+PK4nBelLVoV8gRzJh9d2"
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41)
Cancel-Lock: sha1:8KORCjdDVkPRQZpf01fHdfHFPWU=
In-Reply-To: <vrh9o9$3e7sn$2@dont-email.me>
Bytes: 5599

On Thu, 2025-03-20 at 15:46 +0100, David Brown wrote:
> On 20/03/2025 12:59, bart wrote:
> > On 20/03/2025 08:39, David Brown wrote:
> > > On 19/03/2025 22:29, Chris M. Thomasson wrote:
> > > >=20
> > > > The scares me a bit:
> > > > _____________________
> > > > #include <stdio.h>
> > > >=20
> > > > int main() {
> > > >=20
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 int a =3D 666;
> > > >=20
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 {
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Humm... Odd to =
me...
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int a =3D a;
> > > >=20
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 printf("%d", a);
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 }
> > > >=20
> > > > =C2=A0=C2=A0=C2=A0=C2=A0 return 0;
> > > > }
> > >=20
> > > Yes, that is an unfortunate consequence of the scoping in C - on the=
=20
> > > line "int a =3D a;", the new "a" is initialised with its own unspecif=
ied=20
> > > value, not with the value of the outer "a".
> >=20
> > So the inner 'a' wasn't supposed to mysteriously inherit the outer a's=
=20
> > value? (Perhaps due to sharing the same location.) Since the compilers =
I=20
> > tried just showed zero not 666.
>=20
> No, the inner "a" is completely new and is initialised with itself.=C2=A0=
 As=20
> Keith has pointed out, this is UB - but of course compilers can choose=
=20
> how to implement the code in question.=C2=A0 gcc seems to pick "initialis=
e to=20
> 0" as a default when you write "int a;" and then read "a", and does the=
=20
> same for "int a =3D a;".=C2=A0 Other compilers could choose to do somethi=
ng=20
> different, such as pick a register for "a" and leave the value in the=20
> register unchanged - in which case it might, by luck, pick up the value=
=20
> of the outer "a".

Yes, it (self-reference) should an UB like divide by zero error.
https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/=
download
 .....[cut]
 This guideline has no strong opinion on how this self-ops should be handle=
d,
 yet (it is like divided by zero error). Implement may check the self-ops (=
not
 generally doable) and return ELOOP. Working around might be needed since t=
he
 intent mostly assumes the argument is passed by value, nonetheless a
 theoretical bug might be thus hidden.

IMO, if the compiler sees it, it should issue at least a warning.

> >=20
> > > If the scope of the new variable did not start until after the=20
> > > initialisation, then it would have allowed a number of possibilities=
=20
> > > that would be a lot more useful than the "disable warnings about=20
> > > uninitialised variables" effect or initialisers which refer to their=
=20
> > > own address.=C2=A0 For example :
> > >=20
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int a =3D 123;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int a =3D a;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // local copy that d=
oes not affect the outer one
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
> > >=20
> > >=20
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int a =3D 123;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 long long int a =3D =
a;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Local copy that w=
ith expanded size
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0...
> > >=20
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0for (int a =3D 0; a < 100; a++) {
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const int a =3D a;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // "Lock" the loop i=
ndex to catch errors
> > >=20
> > > As it is, you need to do something like :
> > >=20
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0for (int a =3D 0; a < 100; a++) {
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const int _a =3D a;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const int a =3D _a;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // "Lock" the loop i=
ndex to catch errors
> >=20
> > You mean locking the loop index so it can't be modified?=20
>=20
> Yes.
>=20