Re: int a = a (Was: Bart's Language)

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:

 
The scares me a bit:
_____________________
#include <stdio.h>
 
int main() {
 
     int a = 666;
 
     {
         // Humm... Odd to me...
         int a = a;
 
         printf("%d", a);
     }
 
     return 0;
}

 
Yes, that is an unfortunate consequence of the scoping in C - on the
line "int a = a;", the new "a" is initialised with its own unspecified
value, not with the value of the outer "a".

 
So the inner 'a' wasn't supposed to mysteriously inherit the outer a's
value? (Perhaps due to sharing the same location.) Since the compilers I
tried just showed zero not 666.

 
No, the inner "a" is completely new and is initialised with itself.  As
Keith has pointed out, this is UB - but of course compilers can choose
how to implement the code in question.  gcc seems to pick "initialise to
0" as a default when you write "int a;" and then read "a", and does the
same for "int a = a;".  Other compilers could choose to do something
different, such as pick a register for "a" and leave the value in the
register unchanged - in which case it might, by luck, pick up the value
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 handled,
 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 the
 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.

 

If the scope of the new variable did not start until after the
initialisation, then it would have allowed a number of possibilities
that would be a lot more useful than the "disable warnings about
uninitialised variables" effect or initialisers which refer to their
own address.  For example :
 
     int a = 123;
     {
         int a = a;
         // local copy that does not affect the outer one
     ...
 
 
     int a = 123;
     {
         long long int a = a;
         // Local copy that with expanded size
     ...
 
     for (int a = 0; a < 100; a++) {
         const int a = a;
         // "Lock" the loop index to catch errors
 
As it is, you need to do something like :
 
     for (int a = 0; a < 100; a++) {
         const int _a = a;
         const int a = _a;
         // "Lock" the loop index to catch errors

 
You mean locking the loop index so it can't be modified?

 
Yes.