Kang-Che Sung wrote in
<caddzafmeshwlekmsaw3wcltq6fggr813a0qbe1u793_7xbg...@mail.gmail.com>:
|On Wednesday, September 7, 2022, Steffen Nurpmeso <[email protected]>
|wrote:
...
|>|> + if(su_64( i > U32_MAX || ) i >= UZ_MAX / 2 ||
...
|>|I have to admit that the amount of macro maze makes it really hard to
|>|read ;)
|>
|> Well it is easier than having lots of #ifdef #else #endif blocks
|> in my opinion. On 32-bit the above would spit out a warning
|> (possibly, i have not really looked what compiler/linker flags
|> busybox uses) because i>U32_MAX can never be true. I mean i could
...
|Compiler will optimize out always-false expressions without giving any
|warning.
Regarding the warning: not if you excess an integer limit.
If you say if(0){} i go with you.
Hm. Well, actually it seems current compilers really do so in
simplemost test files at least, like
int main(void){if(10>0xFFFFFFFFFFFFFFFFULL)return 1;return 0;}
But already if it is a bit more complicated there is
int main(void){
unsigned long long int i = 10;
if(i>0xFFFFFFFFFFFFFFFFULL)return 1;
return 0;}
t.c:3:6: warning: result of comparison 'unsigned long long' >
18446744073709551615 is always false [-Wtautological-type-limit-compare]
if(i>0xFFFFFFFFFFFFFFFFULL)return 1;
~^~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
I can assure you that i am surprised, "in earlier times" you would
have been thrown warnings at. (gcc 12.2.0 is silent!!!)
|It's common for C code to produce many expressions like this that evaluate
|to constants (boolean or integer) at compile time as results of macro
|expansion, so no warnings should be given.
|
|The expression with a macro like `su_64( i > U32_MAX || )` looks really
|ugly to me. If what you are achieving is to remove statements that are
|always false (under certain preprocessor condition), just let the compiler
|do the job.
I do not think you are right here.
But sure, as the above is not critical at all, one could simply
use any other much, much lower limit, say, test the 32-bit
100.000.000 limit always, which makes the test expression much
easier. However i have found a bug in that
/* Done for empty expression */
if((i = a_shexp__arith_ws_squeeze(self, exp_buf, exp_len, NIL)) == 0)
goto jleave;
++i;
^ This could have overflowed before. It must be leftover, as we
++i later on (again), which is (then) safe. Ah, what a mess.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
