Undesired behavior (or bug): confirm new variable

[daniel klein]

Consider the following examples:

clear
confirm new variable byte
confirm new variable byte int
confirm new variable _n

None of the above throws an error. I think all of the above should throw an error because all arguments are invalid variable names. Not flagging invalid variable names as such defeats the purpose of confirm.

[William Lisowski]

I agree. Perhaps you should address this to Stata Technical Services.

The following example shows that confirm new variable does not use the same logic as confirm name to confirm that the variable names in newvarlist are valid names.

. confirm new variable a23456789_123456789_123456789_123
a23456789_123456789_123456789_123 invalid name
r(198);

. confirm name a23456789_123456789_123456789_123
a23456789_123456789_123456789_123 invalid name
r(7);

. confirm new variable int

. confirm name int
int invalid name (reserved word)
r(7);

.

Added in edit:

. confirm new frame int

. frame create int

. frame dir
  default  0 x 0
  int      0 x 0

.

shows us that int is not really an invalid name, it's a "reserved word" not available for use as a variable name, but usable for other purposes. Incidentally, [U] 11.2 does not use the term "reserved word", it says "Stata reserves the following names: ... You may not use these reserved names for your variables." So in that sense, the behavior of confirm name is incorrect.

Maybe this is one for the wishlist - a thorough review of the confirm command in the light of the multiple new uses for names in Stata. The confirm name command should probably not reject names that are reserved for variables, but the logic it embodies should be implemented in confirm new variable.