This can be used to check whether untrusted sizes would cause overflow
when used to calculate how much memory is needed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For stable releases, this gives us the ability to make bugfix-only point
releases such as 2.24.1 if we want to, and distinguish between them
programmatically. For example, this ability could have been useful after
2.0.16 to fix Xwayland regressions, and after 2.0.18 to fix event loop
regressions.
For development releases, this gives us the ability to make multiple
prereleases during the same feature cycle, and distinguish between them
programmatically. For example, this would have been useful during 2.0.22
development, which went through three prereleases before reaching the
final release.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that we've said this will be removed from SDL 3, we're free to use
any encoding that is compatible with existing SDL versions and will still
compare correctly for all SDL 2 version numbers. This allows the SDL 2
minor version to go beyond 1 digit, limited only by the size of
SDL_version.minor (which is 8 bits), making the largest possible version
number 2.255.99.
The patchlevel (micro version) is still limited to 2 digits.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The encoding used in SDL_VERSIONNUM (e.g. 2.0.22 -> 2022) cannot
represent 2-digit minor versions without overflowing from the hundreds
digit into the thousands digit, which produces confusing version
numbers that will compare incorrectly when the major version is increased
to 3.
However, we can sidestep this problem by declaring that SDL_VERSIONNUM
will no longer be present in SDL 3, which means it only needs to be able
to represent SDL 2 version numbers losslessly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This comparison normally happens at compile-time, not at runtime, so
it doesn't matter if it isn't optimal. This avoids incorrect comparison
if the minor version in SDL_COMPILEDVERSION and SDL_VERSIONNUM has more
than one digit, which would cause it to overflow from the hundreds place
into the thousands place.
Signed-off-by: Simon McVittie <smcv@collabora.com>
* Add initial support for the Nokia N-Gage
* N-Gage: disable clipping for the time being, issue needs to be resolved later
* Move va_copy definition to SDL_internal.h
* Move stdlib.h include to SDL_config_ngage.h, much cleaner this way
* Remove redundant include, add HAVE_STDLIB_H
* Revert "N-Gage: disable clipping for the time being, issue needs to be resolved later"
This reverts commit 4f5f0fc36cc7f34fad05e45671dfa7b8dc32fd51.
* N-Gage: fix clipping issue by providing proper math functions
This hint allows libdecor to be used even when xdg-decoration is
available. It's mostly useful for debugging libdecor, but could in
theory be used by applications which want to (for example) bundle their
own libdecor plugins.
