https://issues.apache.org/bugzilla/show_bug.cgi?id=46508
--- Comment #6 from [email protected] 2009-01-11 09:12:53 PST --- I really don't want to be picky - httpd isn't my code. Perhaps a c language lawyer will explain the details. As indicated, my experience is that -1 does not necessarily compare equal to unsigned. I've seen (unsigned x == -1)? optimized to false on several compilers. FYI, gcc will warn about comparing signed to unsigned if you ask: cat x.c #include <stdio.h> int main( int argc, char **argv ) { unsigned int x; x = -1; if( argc == 7 ) x = 3; if( x == -1 ) printf( "equal\n" ); else printf( "not\n" ); return 0; } gcc -Wsign-compare x.c -o x.o x.c: In function ‘main’: x.c:10: warning: comparison between signed and unsigned (Yes, on my X86, this case will compare equal). If you make x a short (unlikely in real life), you'll get a "comparison is always false" error. This is correct according to the coersion/promotion rules as I understand them. (They are messier than 'cast to the maximum value x will hold') Another idiom is to compare unsigned x to (~0U/~0UL). You could have UNSET_U defined that way. and then add a cfgMergeUint. But that gets into a change to the whole defaulting mechanism, which seemed beyond the scope of just making this particular function work. You're responsible for the checkin, so I'm not going to pursue this further unless it actually bites me on one of my platforms after release. Thanks again for taking the time to make the checkin. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
