libsdl-org
SDL3: Document what characters portable-format storage paths can contain
So we've already settled on / being the path separator for storage paths for all storage drivers, that's good. But the format of path items between path separators isn't fully specified. Sure, there's maybe just using all lowercase English, the ten decimal digits, underscore, hyphen, and period, but maybe there's more characters safe across all ports? A given storage path is expected to work for all ports, it'd be quite unfortunate for paths in a game to be broken on some platforms.
Edit: Here's an idea, validate the paths in debug SDL builds, but turn that off in release builds.
Edit: Thought about it more, I think the org and app parameters of SDL_OpenUserStorage() should be required to follow the same restrictions as storage path items, since they're the same value for all ports, and have to be able to exist in the filesystem as specified. The requirements are somewhat specified for the same parameters of SDL_GetPrefPath(), but I think a very hard specification of what's allowed is needed. And have something of an explanation somewhere of the difference between "native system path format" and "portable storage path format", and which functions take which format.
@slouken Here's an initial implementation of validation for portable storage paths. It covers a lot of cases, but maybe there's more to check. The validation may even have to be extended in the future, as there could be additional cases found in the future not yet covered.
One potentially controversial validation step I implemented is only allowing lowercase names, to avoid issues with files made on a case insensitive filesystem being stored later on a case sensitive filesystem (developers being sloppy with path strings in their code vs. the on-disk names). An additional validation, of the on-disk name, rejecting on-disk names that contain uppercase characters, would also be in order, if it's decided to only allow lowercase names. Alternatively, the validation code could essentially force case sensitive matching for all platforms, by getting the on-disk name of a file, then comparing it to the storage path string, rejecting it if there's case mismatch.
It turns out, due to Windows, some specific names aren't allowed, not just specific characters. Handling that properly is a bit tricky.
One change I think is needed is around handling com-named files: com.extension shouldn't be allowed, per Windows documentation about reserved names, but longer reverse domain names, like com.example.subdomain, should be allowed. The code as provided rejects all names that start with com., which rejects cases like com.txt. For future-proofing, in the event the other reserved Windows filenames become supported TLDs, names like lpt0.example.subdomain should also be allowed.
Edit: Actually com isn't reserved on Windows, only com0 to com9.