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