[pacman-dev] [PATCH 0/3] Char signedness issues
I tried compiling pacman on my RPi (Arm), where char is unsigned by default. That leads to some things not working the way they are expected too. The problem is as follows: char a = -1; if (a == -1) { ... } If char is unsigned, we will not enter the if-statement (a is converted to int) before making the comparisson. Gcc will warn about these comparissons. The first two patches fixes the cases I (and Gcc) could find, and the third one is a couple of tests I wrote to convince myself there was a problem in pacsort (and more importantly, that the changes actually fixes something). After doing this, I realize that the simplest solution probably would be to add -fsigned-char as an argument to the compiler... thoughts? Rikard Falkeborn (3): Make alpm_graph state signedness explicit pacsort, introduce define for escape_char error code Add pacsort tests with invalid input lib/libalpm/graph.h | 2 +- src/util/pacsort.c | 11 ++++++----- test/util/pacsorttest.sh | 18 +++++++++++++++++- 3 files changed, 24 insertions(+), 7 deletions(-) -- 2.6.4
The signedness of char is implementation defined. Since the
alpm_graph state is clearly meant to be signed, make the
signedness explicit.
This fixes bugs on systems where char is unsigned, in comparissons
of the following type:
if(v.state == -1)
which, if state is unsigned, will never be true due to integer
promotion rules.
Fixes failing test/pacman/tests/sync012.py when compiling with -funsigned-char.
Fixes two warnings [-Wtype-limits] for comparissons with -1 when compiling
with -funsigned-char.
Signed-off-by: Rikard Falkeborn
On 31/12/15 23:19, Rikard Falkeborn wrote:
The signedness of char is implementation defined. Since the alpm_graph state is clearly meant to be signed, make the signedness explicit.
This fixes bugs on systems where char is unsigned, in comparissons of the following type:
if(v.state == -1)
which, if state is unsigned, will never be true due to integer promotion rules.
Fixes failing test/pacman/tests/sync012.py when compiling with -funsigned-char.
Fixes two warnings [-Wtype-limits] for comparissons with -1 when compiling with -funsigned-char.
Pulled.
The signedness of char is implementation defined. On systems where
char is unsigned, comparing a variable of type char with -1 is never
true, due to integer promotion rules. To avoid this, introduce a
define for invalid field separators where -1 is cast to char. This will
ensure that the return value check works for both unsigned and signed char.
Fixes one warning [-Wtype-limits] for comparissons with -1 when compiling
with -funsigned-char.
Signed-off-by: Rikard Falkeborn
On 31/12/15 23:19, Rikard Falkeborn wrote:
The signedness of char is implementation defined. On systems where char is unsigned, comparing a variable of type char with -1 is never true, due to integer promotion rules. To avoid this, introduce a define for invalid field separators where -1 is cast to char. This will ensure that the return value check works for both unsigned and signed char.
Fixes one warning [-Wtype-limits] for comparissons with -1 when compiling with -funsigned-char.
Signed-off-by: Rikard Falkeborn
OK.
Signed-off-by: Rikard Falkeborn
participants (2)
-
Allan McRae
-
Rikard Falkeborn