[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #13, bug #34608 (project make): Doing it at configure time is quite easy, and just as portable. Specifying negative array lengths will reliably fail at compile time. This trick is already used by several autoconf tests (including AC_COMPUTE_INT last I looked). Again, what you

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #12, bug #34608 (project make): Doing it at configure time is surprisingly difficult. You have to remember that, for any package which wants to properly cross-compile (which we do), you can't actually RUN any test programs during configure time. In order to test it you'd need t

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #11, bug #34608 (project make): Don't reopen this for me, but you might consider doing this check at configure time. >From a quick look, I didn't see something like AC_IS_SIGNED. However it shouldn't be hard to wrap AC_COMPILE_IFELSE around an array-bound test that triggers a f

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #10, bug #34608 (project make): Very nice, thanks! ___ Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.o

[bug #34608] comparison of unsigned expression < 0 is always false

Update of bug #34608 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #8, bug #34608 (project make): Not sure why that happens although the C standard requires special handling of char in various ways. The warnings you're seeing in the source, though, are related to invoking this macro with uintmax_t not char.

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #7, bug #34608 (project make): Interesting. For you code (with "unsigned int") I get the warning, too. For "unsigned char", I don't. No warnings in either case for "> 0" (as opposed to ">= 0". ___ Reply to this item at:

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #6, bug #34608 (project make): This is what I get: $ cat foo.c #define INTEGER_TYPE_SIGNED(t) !((t) -1 >= 0) int foo() { return INTEGER_TYPE_SIGNED(unsigned int); } $ gcc --version gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5 $ gcc -Wextra -g -c -o foo.o foo.c foo.c: In function

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #5, bug #34608 (project make): You mentioned !((t) -1 >= 0) . I do not get any warnings when using that in the mentioned code sample compiled with -Wall -Wextra and GCC 4.4.5. What warnings do you get? ___ Reply to this i

[bug #34608] comparison of unsigned expression < 0 is always false

Update of bug #34608 (project make): Status: Not A Bug => None Open/Closed: Closed => Open ___ Reply to this item at:

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #4, bug #34608 (project make): Can you re-open the bug until you made a decision? ___ Reply to this item at: ___ Message sent via/by S

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #3, bug #34608 (project make): Hm. This change is not identical to the original. To get that you'd need to write !((t) -1 >= 0) and if you do that then GCC warns again. However I'm not aware offhand of any numeric implementations where casting a -1 to an unsigned value yields

[bug #34608] comparison of unsigned expression < 0 is always false

Follow-up Comment #2, bug #34608 (project make): Thanks for these details. Let me propose #define INTEGER_TYPE_SIGNED(t) !((t) -1 > 0) for a warning-less replacement then. Like it? Please re-open the bug for me, as I lack permissions to. I used the program below with # gcc -Wall -Wextra

[bug #34608] comparison of unsigned expression < 0 is always false

Update of bug #34608 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: It turns out that this