[PATCH] ussd: Fix text of RELEASE COMPLETE

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.vu
Tue Oct 8 09:51:42 UTC 2013


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.

Kind regards,
-Alex




More information about the OpenBSC mailing list