This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Alexander Huemer alexander.huemer at xx.vuOn 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.
Kind regards,
-Alex