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,
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