On Wed, Jan 03, 2007 at 05:06:54PM +0000, Dave Evans said:
> On Wed, Jan 03, 2007 at 08:46:28AM -0800, Marc Perkel wrote:
>
> > A null and a blank string are not the same thing either. Are you going
> > to treat strings that way too?
>
> Not a fair comparison IMO, because although variables can be null, the result
> of string expansion can (AFAIK) never be null. (e.g. h_Cc may be null, but
> expanding $h_Cc: yields the empty string). Since the operands of string ops
> (e.g. eq) are always acquired by first performing a string expansion, which
> can *only* yield a (possibly empty) string, the operands can never be anything
> but strings. Unless I've missed something.
Compile and run this if you're not sure about the difference between
null and empty:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p = NULL;
printf ("p is '%s'\n", p);
p = "";
printf ("p is '%s'\n", p);
exit(0);
}
I hate to agree with Perkel, but if we're already doing a conversion
from null char pointer to empty char string, it really doesn't seem any
different to do the same thing for integer comparison.
It doesn't particularly make sense to me to treat this as an error:
${if ={$acl_m0}{0}}
and not this:
${if eq{$acl_m0}{}}
Introducing consistency would mean that you would have to test every
variable with def before using it, which really gets tedious, and means
to me that that test should probably be left to the parser.
--
--------------------------------------------------------------------------
| Stephen Gran | The road to ruin is always in good |
| steve@??? | repair, and the travellers pay the |
| http://www.lobefin.net/~steve | expense of it. -- Josh Billings |
--------------------------------------------------------------------------
