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