-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Description
Hello.
TLDR I think I discovered a bug in SDL_genericstorage.c and an issue with opendir
in SDL_sysfsops.c (on Linux). Passing an empty string to SDL_OpenFileStorage
comes with bad surprises.
For a while in my application I've been accessing files on the disk using SDL_OpenFileStorage
, SDL_ReadStorageFile
and SDL_WriteStorageFile
. I've been passing an empty string to SDL_OpenFileStorage
to indicate the current (relative) working directory and it worked perfectly:
m_storage = SDL_OpenFileStorage("");
However, I realized now that SDL_GlobStorageDirectory
doesn't work with an empty string. It crashes in SDL_genericstorage.c in GENERIC_EnumerateStorageDirectory
, because userdata
is NULL
and it is passed to SDL_strlen
. After reading the documentation, it looks like often an empty string is analogous to a null pointer, at least to the API. userdata
, as far as I understand, can be null (no base path). So that looks like a bug that might be fixed like so:
if (fullpath) {
wrap_data.base_len = userdata ? SDL_strlen((char *)userdata) : 0;
wrap_data.real_callback = callback;
Even after that, SDL_GlobStorageDirectory
was failing to open a directory (no such file or directory) in SDL_sysfsops.c in SDL_SYS_EnumerateDirectory
, because opendir
fails when it receives empty strings. It was trying to open the root directory of the file storage:
int count {};
char** files {SDL_GlobStorageDirectory(m_storage, nullptr, pattern, 0, &count)};
For now, I fixed all of my problems by passing the current full path working directory to SDL_OpenFileStorage
, instead of an empty string. However, if SDL_OpenFileStorage
indeed supports relative paths (which it looks like it sometimes does), then that also looks like an issue. If I misunderstood and misused SDL_OpenFileStorage
all this time, then I suggest maybe updating the documentation, to warn against bad paths.