8 Oct
2013
8 Oct
'13
1:16 p.m.
On Tue, Oct 08, 2013 at 12:49:56PM +0200, Holger Hans Peter Freyther wrote:
On Tue, Oct 08, 2013 at 11:59:09AM +0200, Alexander
Huemer wrote:
Dear Alexander,
No smoking gun that I know of.
It's just that the interaction between the piece of code in libosmocore
and the piece in openbsc cannot work as the author intended.
Well, as I see it the test against 0xFF is not
true under any
circumstances, as long as the code is not intentionally compiled with
-funsigned-char. If there is an undesired behavior change because of
this code change, it's a bug. What's your opinion?
well, I agree that it is not nice and we can/should change it to a
plain null termination. What I doubt that it is currently a problem
or can you present a smoking gun? int main(int argc, char **argv)
{
signed char a = 0xFF;
signed char b = 0xFF;
if (a == b)
printf("THE SAME\n");
return 0;
}
Yes, that works of course, but I think my example program better
illustrates the current situation in libosmocore and openbsc. In
libosmocore a value is assigned which is truncated, in openbsc a
comparison is made again that same value and this test returns false,
though the intension was to return true.
PS: some ABIs.. e.g. ARM ones.. char will be unsigned.
I only tested the patches on x86_64, but '\0' should be safe on all
architectures.
Kind regards,
-Alex