From:             AxelLuttgens at swing dot be
Operating system: Darwin 7.0.0 (Panther)
PHP version:      4.3.3
PHP Bug Type:     Compile Warning
Bug description:  Comparison always false in var_unserializer.c

Description:
------------
I know this has already been reported, with reassuring replies such as
"that warning may be safely ignored" or "there is no need to fix this
one".

A a reminder, the message goes so:

var_unserializer.c:308: warning: comparison is always false due to limited
range of data type

(I tried with PHP 4.3.3, as well as with php4-STABLE-200311020830: same
results)

I am of the opinion that it is just lucky programming that it works now,
and that the whole matter could easily break in case of a slight change in
the code.

I don't know much about re2c, but I think I can guess how it works by
comparing the .re and the resulting .c files.
So, looking at the var_unserializer.re file, these lines seem to be the
relevant ones:

0086: #define YYCTYPE unsigned char
0097: any = [\000-\277];
0411: any       { return 0; }
0415:   return 0;

Corresponding lines in var_unserializer.c are:

0087: #define YYCTYPE unsigned char
0308:                 if(yych <= '\277') goto yy15;
0309:             }
0310:         }
0311:     }
0312: yy2: YYCURSOR = YYMARKER;
0313:     switch(yyaccept){
0314:     case 0: goto yy4;
0315:     }
0319: yy4:
0320:     { return 0; }
0359: yy15: yych = *++YYCURSOR;
0360:     goto yy4;

In the comparison, yych is promoted to an unsigned in, while (on lots of
systems) '\277' is promoted to a signed int, hence the comparison
failure.

Now, the lucky part is that yyaccept is never set in the code and thus
keeps its initialisation value (ie, zero).
So, jumping to yy15 or continuing execution through yy2 have finally the
same effect...

But the question is: shouldn't the any symbol be defined as 
[\000-\377] instead of [\000-\277]?

If it is the case, I guess re2c would just forget about comparisons with
characters having decimal code greater than 127.
And one would thus alleviate spurious warnings.

If it isn't the case, well, my apologies ;-)

HTH
Axel



-- 
Edit bug report at http://bugs.php.net/?id=26078&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26078&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26078&r=trysnapshot5
Fixed in CVS:               http://bugs.php.net/fix.php?id=26078&r=fixedcvs
Fixed in release:           http://bugs.php.net/fix.php?id=26078&r=alreadyfixed
Need backtrace:             http://bugs.php.net/fix.php?id=26078&r=needtrace
Try newer version:          http://bugs.php.net/fix.php?id=26078&r=oldversion
Not developer issue:        http://bugs.php.net/fix.php?id=26078&r=support
Expected behavior:          http://bugs.php.net/fix.php?id=26078&r=notwrong
Not enough info:            http://bugs.php.net/fix.php?id=26078&r=notenoughinfo
Submitted twice:            http://bugs.php.net/fix.php?id=26078&r=submittedtwice
register_globals:           http://bugs.php.net/fix.php?id=26078&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26078&r=php3
Daylight Savings:           http://bugs.php.net/fix.php?id=26078&r=dst
IIS Stability:              http://bugs.php.net/fix.php?id=26078&r=isapi
Install GNU Sed:            http://bugs.php.net/fix.php?id=26078&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26078&r=float

Reply via email to