On Tue, Oct 08, 2013 at 11:27:49AM +0200, Holger Hans
Peter Freyther wrote:
On Sun, Oct 06, 2013 at 09:55:09PM +0200,
Alexander Huemer wrote:
Before the assigned value (0xFF) was truncated,
reg->text[0] is of
type char. A corresponding test for the same value in openbsc could
only fail.
Can you please explain?
char is an signed 8bit type, so the maximum value is 0x7F. Well, at
least usually. As I read, ANSI C does not dictate whether a variable
declared as 'char' is signed or unsigned, gcc though defaults to signed.
Excerpt from limits.h:
[...]
# define SCHAR_MAX 127
[...]
# ifdef __CHAR_UNSIGNED__ (this is not the case normally)
[...]
# define CHAR_MAX SCHAR_MAX
[...]
Example program:
int main(void)
{
char c = 0xFF;
if (c == 0xFF)
return 0;
return 1;
}
gcc gives a hint when -Wtype-limits is used.
$ gcc -Wtype-limits main.c
$ ./a.out
main.c: In function ‘main’:
main.c:5:2: warning: comparison is always false due to limited range of
data type [-Wtype-limits]
$
signed char a = 0xFF;
signed char b = 0xFF;
a == b => true. Even if the numerical is not the one, one expected?
This is true because _both_ variables got the same truncated literal.
A week has passed since the last comment on this (and my other) patch.
What is the current state? Are the two patches rejected because they do
not make sense? Should I modify anything? Will they be merged at some
point in the future?
Kind regards,
-Alex