I have not thought about this issue before,
so I decided to do a little experimentation.
Here is my 2c worth, in point form.
1) There is no point in any discussion about NULL pointers
vs empty strings. This is not C. This is closer to
a macro substitution language, ala shell or CPP.
The question is what to do with an expansion that is
not defined when cast to an integer or possibly more
corectly what is the result of casting an empty string
to an integer. No other discussion is relevent.
2) The Bourne shell will allow strings to be compared with
integers. In the case of an empty string, the cast of the
string to an int seems to result in zero.
eg if test "" -eq 0
But so does any string that cannot be converted
eg if test "fred" -eq 0
Of course, expansion of undefined macros does not result
in implicitly quoted strings so
undef X
if test $X -eq 0
is a syntax error.
The above is true for Bourne and Korn shells, but BASH seems to get
it wrong
if test "" -eq 0
in BASH generates a syntax error. This may be a bug. POSIX anyone?
3) In CPP, things are odd.
#undef X
#if X == 0
X is 0
#endif
will output X is 0
Interestingly
#define X fred
#if X == 0
X is 0
fi
also outputs X is 0
So, it appears both shell and CPP allow casting any arbitrary
string to an int, and if the conversion fails, the result is the
integer 0.
In python, casting "" to int is an error but casting
nothing to an int gives 0 (I consider this odd).
In C, atoi("") works fine and produces 0 with errno set to 0 as well.
So, of the systems I tested, only python thinks casting an empty
string to an integer does not result in zero, and strangely
it thinks casting nothing to an integer is OK. Bizarre!
So finally, given that other people seem to have thought about this before us
and most have decided that casting empty strings to integers is legal
and results in zero particulary in macro languages and it was the previous
behaviour -
I vote for that.
Regards,
pdg
--
See mail headers for contact information.
