[PATCH] ussd: Fix text of RELEASE COMPLETE

[Alexander Huemer]

On Tue, Oct 08, 2013 at 11:51:42AM +0200, Alexander Huemer wrote:
> 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