[RFC] use unsigned chars #2768
[RFC] use unsigned chars #2768
Conversation
This matches what the kernel does. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
This matches what the kernel does. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
|
In any case I think meson should be aligned with Autotools, which currently is not the case. |
|
I agree that we need to sync meson and autotools. Personally, I prefer when developers are explicit and always use "unsigned" in the code. Is there anything we can break with the change? I mean things like any encoding, etc. For example, in the very old lib/mangle.c is used "const char" rather than "unsigned" (probably no issue as it uses 'signed' in all the code) etc. |
There are things that could break. But given that the signedness of plain 'char' already changes per architecture. (signed for x86, unsigned for arm), things should already be broken. |
|
We use |
Not on meson. |
|
Ah, now I understand ;-) OK, so let's go ... |
|
We should check if |
All over the place. Which means we already had mismatches between API users and API implementations in the autotools binaries. |
|
That's a good point. It's also more complicated because we do not control how public libs API header files are interpreted if a signed/unsigned keyword is missing. Hmm... the libmount or libblkid headers are full of 'char'; adding 'unsigned' everywhere will be an API change. |
|
On the other hand there is already a mismatch between what the users expect (naive char) with what util-linux interprets (signed char with autotools). I guess as a first step we can align meson to autotools with |
This matches what the autotools build is doing. Also see util-linux#2768 . Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
|
It is my opinion or understanding that most stuff out there assumes chars are unsigned, this is a naive assumption but it is what most programs assume. |
This matches was the kernel does.
It also aligns meson with autotools.