We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3764 - SDL_iconv_string doesn't properly signal an error with invalid input sizes
Summary: SDL_iconv_string doesn't properly signal an error with invalid input sizes
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.0
Hardware: All All
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-21 15:36 UTC by Simon Hug
Modified: 2017-08-30 07:06 UTC (History)
0 users

See Also:


Attachments
A little test case for wrong usage of SDL_iconv_string. (1.81 KB, text/x-csrc)
2017-08-21 15:36 UTC, Simon Hug
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hug 2017-08-21 15:36:36 UTC
Created attachment 2869 [details]
A little test case for wrong usage of SDL_iconv_string.

SDL_iconv_string can return without encoding all characters and then doesn't signal that an error happened, like returning NULL. This only seems to be possible if the user makes a mistake and calculates the size of the string wrong. The SDL implementation of iconv may throw SDL_ICONV_EINVAL in that case and SDL_iconv_string essentially just exits with the unfinished string.

SDL is not responsible for user error, but I think it should signal that something went wrong. If the last character is expected to be a terminating zero and it is missing, well... we all known to what kind of bugs that leads.

Since SDL_iconv_string allocates plenty of memory, I also propose that it always adds a terminating zero at the end.

The attached program converts a string four times and dumps the memory.

I did not test any iconv implementations outside of SDL yet. I'm guessing it's also a problem there.
Comment 1 Sam Lantinga 2017-08-30 07:06:43 UTC
I agree this should be fixed, but I'd like to research what different platforms do in this case, and it doesn't need to hold up 2.0.6.