www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - unenforced errors for local variable

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
According to the documentation (see Local Variables in 
http://www.digitalmars.com/d/function.html) the following code contains 5 
errors (ie - none of the errors in that section are obeyed):
int* foo() {
  int x;
  int y = x+1;
  int z;
  printf("%d %d\n",x,y);
  {
    double x = 3.3;
    printf("%lf %d\n",x,y);
    goto x;
  }
x:
  return &x;
}
void main(){ foo(); }

The errors:
1) x is used before being assigned
2) z is unused
3) the inner x hides the outer x
4) the address of a local variable is returned
5) a local variable x and a label have the same name

The doc for the first error says "the implementation may not be able to 
detect all cases of using a variable before assigning it" but one would hope 
the reference compiler would be able to enforce the errors for the code 
given. Currently it is very easy to write code that compiles fine but turns 
out to be illegal according to the doc.
Mar 18 2005
parent reply Kramer <Kramer_member pathlink.com> writes:
In article <d1f8v6$1kt6$1 digitaldaemon.com>, Ben Hinkle says...

According to the documentation (see Local Variables in 
http://www.digitalmars.com/d/function.html) the following code contains 5 
errors (ie - none of the errors in that section are obeyed):
int* foo() {
  int x;
  int y = x+1;
  int z;
  printf("%d %d\n",x,y);
  {
    double x = 3.3;
    printf("%lf %d\n",x,y);
    goto x;
  }
x:
  return &x;
}
void main(){ foo(); }

The errors:
1) x is used before being assigned


I'm confused on point 1.  If certain types have initial default values that are
in a usable state (i.e. int's), why would this be an error?  Or is it a blanket
statement to also cover user-defined types that may not have been given a
default value?


2) z is unused
3) the inner x hides the outer x
4) the address of a local variable is returned
5) a local variable x and a label have the same name

The doc for the first error says "the implementation may not be able to 
detect all cases of using a variable before assigning it" but one would hope 
the reference compiler would be able to enforce the errors for the code 
given. Currently it is very easy to write code that compiles fine but turns 
out to be illegal according to the doc.
Mar 18 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
The errors:
1) x is used before being assigned


 I'm confused on point 1.  If certain types have initial default values 
 that are
 in a usable state (i.e. int's), why would this be an error?  Or is it a 
 blanket
 statement to also cover user-defined types that may not have been given a
 default value?


The default value is also used to initialize fields and fill in dynamically 
allocated arrays (although the compiler ignores them when resizing though 
assigning the "length" - that's probably a bug, too). Personally I would 
make all the default values 0 (or null) and remove the (currently 
unenforced) error for unassigned local vars. It is much easier to remember 
the rule "all data is initialized to 0" than various rules like "local 
variables must be explicitly assigned and int-like fields are initialized to 
0 in classes and structs and floating-point and chars are initialized to 
unusable values so they must effectively be initialized explicitly, too, but 
it isn't required (at least by the doc - the compiler doesn't actually check 
for assignment)". Life is complicated enough without having to worry about 
nuances in default values :-P


2) z is unused
3) the inner x hides the outer x




These two I could see being allowed - it's handy to allowed unused variables 
during debugging. Plus scopes are all about short-lived declarations so it 
isn't unusual to hide a variable in an outer scope for a few lines. I 
suppose it would be nasty to hide a variable for large blocks of code but 
that doesn't seem much different than hiding in any other context (eg - 
local vars hiding data members or globals).
Mar 18 2005
parent Kramer <Kramer_member pathlink.com> writes:
In article <d1fdqc$236a$1 digitaldaemon.com>, Ben Hinkle says...

The errors:
1) x is used before being assigned


 I'm confused on point 1.  If certain types have initial default values 
 that are
 in a usable state (i.e. int's), why would this be an error?  Or is it a 
 blanket
 statement to also cover user-defined types that may not have been given a
 default value?


The default value is also used to initialize fields and fill in dynamically 
allocated arrays (although the compiler ignores them when resizing though 
assigning the "length" - that's probably a bug, too). Personally I would 
make all the default values 0 (or null) and remove the (currently 
unenforced) error for unassigned local vars. It is much easier to remember 
the rule "all data is initialized to 0" than various rules like "local 
variables must be explicitly assigned and int-like fields are initialized to 
0 in classes and structs and floating-point and chars are initialized to 
unusable values so they must effectively be initialized explicitly, too, but 
it isn't required (at least by the doc - the compiler doesn't actually check 
for assignment)". Life is complicated enough without having to worry about 
nuances in default values :-P


Heartily agree with above.


2) z is unused
3) the inner x hides the outer x




These two I could see being allowed - it's handy to allowed unused variables 
during debugging. Plus scopes are all about short-lived declarations so it 
isn't unusual to hide a variable in an outer scope for a few lines. I 
suppose it would be nasty to hide a variable for large blocks of code but 
that doesn't seem much different than hiding in any other context (eg - 
local vars hiding data members or globals).
Mar 18 2005