-
-
Notifications
You must be signed in to change notification settings - Fork 522
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
[Enhancement] Use correct data types #605
Comments
A laudable goal, but there are many, many spots where the types can't change as doing so would break API/ABI compatibility. |
Oh yes I understand, that's the disadvantage.
(Atm I don't see anything else) Modules must have to be recompiled. Modifying functions shouldn't cause issues for game/cgame modules as they use traps (if they remain unchanged). And the renderer module could get "proxy" functions as import (like About structs, maybe create new integer types? For example, |
The suggestion is to fix all data-type related mistakes, like for example :
const
fix example:Using
const
means the caller knows that the string will never be modified, it would be then more safe to use string literals as input.size_t
example:By using
size_t
, the caller knows that the function's input is a size-type. It would be more consistent with x64 code, it could be possible to allocate memory above 4GB (although it won't ever happen), and it would be more compatible with the C standard library that returnsize_t
.It would also mean that there will never be a size below 0 as
size_t
is unsigned.FS size example:
Opening files above 4GB could then be possible.
I'm aware about the challenge of fixing the whole codebase. 🙂
Having the correct type can hint developers about the usage.
The text was updated successfully, but these errors were encountered: