Skip to content

sdl2::ttf::init incorrectly incorrectly uses the last OS error. #1347

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.

Sign up for GitHub

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

Jump to bottom
Closed
sprocklem opened this issue Nov 4, 2023 · 0 comments
Closed

sdl2::ttf::init incorrectly incorrectly uses the last OS error. #1347

sprocklem opened this issue Nov 4, 2023 · 0 comments

Comments

@sprocklem
Copy link

init assumes that only OS errors are encountered during initialization, but this is not the case since the underlying FT_Init_FreeType has other error conditions. Instead, init should get the error from SDL_GetError as documented here (TTF_GetError is #defined as SDL_GetError).

To retain backwards compatibility with the current error type, it may be necessary to wrap the error in an Error with ErrorKind::Other.
sprocklem pushed a commit to sprocklem/rust-sdl2 that referenced this issue Nov 4, 2023
ttf: Use SDL_GetError for initialization errors
817121e 
Previously, the code use the last OS error. However, not all errors
returned by `TTF_Init` are OS errors, and the expected behaviour is that
the caller instead use `SDL_GetError` when an error is encountered.

To limit breakage for existing application the error is still returned
as an `io::Error`, albeit one with `io::ErrorKind::Other`. It is
worth noting that this does lead to an observable difference in
behaviour for callers – the error has a different kind – although any
code that is inspecting this was already relying on an unreliable source
of data.

This fixes issue Rust-SDL2#1347.
@sprocklem sprocklem mentioned this issue Nov 4, 2023
Closed
sprocklem pushed a commit to sprocklem/rust-sdl2 that referenced this issue Nov 4, 2023
Fix "sdl2::ttf::init incorrectly incorrectly uses the last OS error"
fc5fce8 
Previously, the code use the last OS error. However, not all errors
returned by `TTF_Init` are OS errors, and the expected behaviour is that
the caller instead use `SDL_GetError` when an error is encountered.

To limit breakage for existing application the error is still returned
as an `io::Error`, albeit one with `io::ErrorKind::Other`. It is
worth noting that this does lead to an observable difference in
behaviour for callers – the error has a different kind – although any
code that is inspecting this was already relying on an unreliable source
of data.

This fixes issue Rust-SDL2#1347.
sprocklem pushed a commit to sprocklem/rust-sdl2 that referenced this issue Nov 4, 2023
Use SDL_GetError for sdl2::ttf::init instead of the last OS error
74f17f1 
Previously, the code use the last OS error. However, not all errors
returned by `TTF_Init` are OS errors, and the expected behaviour is that
the caller instead use `SDL_GetError` when an error is encountered.

To limit breakage for existing application the error is still returned
as an `io::Error`, albeit one with `io::ErrorKind::Other`. It is
worth noting that this does lead to an observable difference in
behaviour for callers – the error has a different kind – although any
code that is inspecting this was already relying on an unreliable source
of data.

This fixes issue Rust-SDL2#1347.
sprocklem pushed a commit to sprocklem/rust-sdl2 that referenced this issue Nov 4, 2023
Use SDL_GetError for sdl2::ttf::init instead of the last OS error
dd3721b 
Previously, the code use the last OS error. However, not all errors
returned by `TTF_Init` are OS errors, and the expected behaviour is that
the caller instead use `SDL_GetError` when an error is encountered.

To limit breakage for existing application the error is still returned
as an `io::Error`, albeit one with `io::ErrorKind::Other`. It is
worth noting that this does lead to an observable difference in
behaviour for callers – the error has a different kind – although any
code that is inspecting this was already relying on an unreliable source
of data.

This fixes issue Rust-SDL2#1347.
antonilol added a commit to antonilol/rust-sdl2 that referenced this issue Oct 8, 2024
@antonilol
prevent users from creating Sdl2TtfContext out of nothing
b9677d9 
various other changes:
- allow multiple `ttf::init` calls, the same way it works with TTF_Init
- return last sdl error instead of I/O error (like stale pr Rust-SDL2#1348, fixes Rust-SDL2#1347 and closes Rust-SDL2#1348)
- implement `Clone` for `Sdl2TtfContext`, SDL C code will do the reference counting
- make `ttf::font::internal_*` `pub(super)`
- make `ttf::font::Font::raw` safe (obtaining a raw pointer is safe, using it is unsafe)
antonilol added a commit to antonilol/rust-sdl2 that referenced this issue Oct 8, 2024
@antonilol
prevent users from creating Sdl2TtfContext out of nothing
c4e74c7 
and various other changes, including:
- allow multiple `ttf::init` calls, the same way it works with TTF_Init
- return last sdl error instead of I/O error (like stale pr Rust-SDL2#1348, fixes Rust-SDL2#1347 and closes Rust-SDL2#1348)
- implement `Clone` for `Sdl2TtfContext`, SDL C code will do the reference counting
- make `ttf::font::internal_*` `pub(super)`
- make `ttf::font::Font::raw` safe (obtaining a raw pointer is safe, using it is unsafe)
antonilol added a commit to antonilol/rust-sdl2 that referenced this issue Mar 8, 2025
@antonilol
prevent users from creating Sdl2TtfContext out of nothing
04e9b69 
and various other changes, including:
- allow multiple `ttf::init` calls, the same way it works with TTF_Init
- return last sdl error instead of I/O error (like stale pr Rust-SDL2#1348, fixes Rust-SDL2#1347 and closes Rust-SDL2#1348)
- implement `Clone` for `Sdl2TtfContext`, SDL C code will do the reference counting
- make `ttf::font::internal_*` `pub(super)`
- make `ttf::font::Font::raw` safe (obtaining a raw pointer is safe, using it is unsafe)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sprocklem