On Fri, 2012-12-21 at 15:37 +0200, Daniel Golle wrote:
> 
> So yes, the condition in the while-loop will always be false, as *src is of 
> type
> char* which is identical to uint8_t, at least on my target platform 
> (arm_v5te).
> I'm too lazy to get all the way into what is actually supposed to happen 
> there,
> but as far as I remember, you should use signed char or int8_t if you intend 
> to
> use signed 8-bit integers.

This is partly fixed by commit 28cb28d0 upstream¹, but not completely.
The 'hexvals' array is still an unsigned char, so the comparison
'hexvals[…] < 0' is *also* always false, giving the same warning. You
can easily reproduce this on x86 by adding '-funsigned-char' to the
compiler command line:

[dwmw2@shinybook odhcp6c]$ make C_DEFINES="-D_GNU_SOURCE -funsigned-char" 
Scanning dependencies of target odhcp6c
[ 25%] Building C object CMakeFiles/odhcp6c.dir/src/script.c.o
/home/dwmw2/git/odhcp6c/src/script.c: In function ‘script_unhexlify’:
/home/dwmw2/git/odhcp6c/src/script.c:62:5: error: comparison is always false 
due to limited range of data type [-Werror=type-limits]
cc1: all warnings being treated as errors

diff --git a/src/script.c b/src/script.c
index 66a15a7..dd7facf 100644
--- a/src/script.c
+++ b/src/script.c
@@ -24,7 +24,7 @@
 #include "odhcp6c.h"
 
 static const char hexdigits[] = "0123456789abcdef";
-static const char hexvals[] = {
+static const signed char hexvals[] = {
     -1, -1, -1, -1, -1, -1, -1, -1, -1, -2, -2, -1, -1, -2, -1, -1,
     -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
     -2, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,

-- 
dwmw2

¹ https://github.com/sbyx/odhcp6c/commit/28cb28d0

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to