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 12:49:56PM +0200, Holger Hans Peter Freyther wrote:
> On Tue, Oct 08, 2013 at 11:59:09AM +0200, Alexander Huemer wrote:
>
> Dear Alexander,
>
> > 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?
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.
> 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