Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of plain char as signed char in libc is not optimal #1942

Open
jmalak opened this issue Jul 28, 2024 · 0 comments
Open

Use of plain char as signed char in libc is not optimal #1942

jmalak opened this issue Jul 28, 2024 · 0 comments

Comments

@jmalak
Copy link
Contributor

jmalak commented Jul 28, 2024

With regard to improve OpenWatcom stuff I found one case where libc could be improved get it smaller a little bit.
The libc library is primarily compiled by gcc (16-bit) and it uses signed char (default) for plain char, but OpenWatcom uses unsigned char (default). When I play with OpenWatcom stuff improvement I checked generated code and using of unsigned char for plain text get smaller generated code.
Anyway now it is mismatch between GCC and OpenWatcom that it should be corrected.

Simple solution is switch OpenWatcom to use signed char for plain char, because most of testing was done with executable generated by GCC with signed char type for plain char, but code will be a little bigger.
Unsigned char get a little bit smaller code that it can be switch to use unsigned char also for GCC, but it is not possible without review of code which use plain char because there can be issue with signed/unsigned values not generally but on some places in code.

This issue is rather for future development to optimize size of ELKS libc.

@jmalak jmalak changed the title Use of plain char as signed char is not optimal Use of plain char as signed char in libc is not optimal Jul 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant