SDL 2.30.2 Released Along WIth New SDL3 Preview

[phoronix]

Phoronix: SDL 2.30.2 Released Along WIth New SDL3 Preview

The Simple DirectMedia Layer software/hardware abstraction layer commonly used by games and other cross-platform software is out with a new SDL 2.30.2 stable release as well as a new SDL3 preview release...

https://www.phoronix.com/news/SDL-2.30.2-SDL3-Preview-2

[billyswong]

- Case insensitive string comparison functions are no longer affected by locale

I remember the stupid quirk of Turkish not mapping I and i as the uppercase/lowercase pair. I wonder if SDL is treating everything as if English being the ultimate standard?

[anda_skoa]

Given the mention of controllers and mapping in both article and changelog: anyone know why it is apparently so difficult for games to detect at least the type of controller?

I've seen so many games, even from big studios, which are utterly incapable of doing that and end up with a shitty game play experience like displaying the wrong button hints.

Do the gaming APIs all hide this information or are game developers simply not aware that different controllers have different button symbols?

[ssokolow]

I remember the stupid quirk of Turkish not mapping I and i as the uppercase/lowercase pair. I wonder if SDL is treating everything as if English being the ultimate standard?

I'm guessing they're probably running their comparisons in the C locale, also known as the POSIX locale... which treats ASCII as the ultimate standard. (I just woke up, so I'm a little too out of it right now to read the spec and see what it does for bytes outside the range of 0 to 127, but I'm guessing it just considers anything that's not a-z or A-Z to not be a letter.)

Setting the appropriate locale environment variables to C before performing filesystem-related string operations in C is actually something I've seen as advice in various i18n guides to ensure that Turkish systems don't break applications written and tested in the English-speaking world. (Not surprising for a language that originated on a case-sensitive OS where doing anything other than treating filenames as opaque tokens or splitting/adding extensions was a bug... to the point where you'd see stuff like ".c is C code and .C is C++ code" and similar for .z vs .Z.)

[Jaxad0127]

I remember the stupid quirk of Turkish not mapping I and i as the uppercase/lowercase pair.

You mean Turkish having two distinct letters here: undotted (I and ı) and dotted (İ and i)?

[ssokolow]

You mean Turkish having two distinct letters here: undotted (I and ı) and dotted (İ and i)?

In English, i uppercases into I and and I lowercases into i. In Turkish, those relationships exist between I and ı and between İ and i, not between I and i.

The most common way this breaks things is Windows-style "load a file without caring to ensure the filename's case matches" or "compare a string against a compiled-in constant, case-insensitively". (The former is also why it can be a pain to get game mods working on Linux if they're not stored on a case-insensitive filesystem... you have to go through, renaming each file that gets called out in an error message until all the cases match.)

[anda_skoa]

In English, i uppercases into I and and I lowercases into i. In Turkish, those relationships exist between I and ı and between İ and i, not between I and i.

How would that be an issue?
Both Turkish characters have a lower case and upper case variant, so any comparison should be able to use the same algorithm for performing case insensitive matches.

The random similarities with latin characters would only be an issue if inspected visually.

[ssokolow]

How would that be an issue?
Both Turkish characters have a lower case and upper case variant, so any comparison should be able to use the same algorithm for performing case insensitive matches.

The random similarities with latin characters would only be an issue if inspected visually.

Because you might have Images.pak on disk and open_pak("images.pak") in your source code or vice-versa and it tests working on North American Windows systems. The Turkish locale then comes along and breaks that uppercase-lowercase pairing.

[anda_skoa]

Because you might have Images.pak on disk and open_pak("images.pak") in your source code or vice-versa and it tests working on North American Windows systems. The Turkish locale then comes along and breaks that uppercase-lowercase pairing.

Aside from the fact that somebody seemed to have been unable to copy&paste a file name or type it correctly: how would Turkish locale affect that given that both file name and code are presumable ASCII or UTF-8?

None of the characters would be the Turkish ones that look similar.

If the file name was "Positions.dat" the "P" would suddenly become the cyrillic character for R when running in a Russian locale just because it looks similar to P.

[ssokolow]

Aside from the fact that somebody seemed to have been unable to copy&paste a file name or type it correctly: how would Turkish locale affect that given that both file name and code are presumable ASCII or UTF-8?

Because people writing software don't always copy-paste filenames. They'll re-type them and, if it works under test, they'll move on... and Windows uses case-insensitive filename resolution.

None of the characters would be the Turkish ones that look similar.

Actually, they are. That's the problem. Turkish codepages reused the ASCII characters but altered the uppercase-lowercase pairings and Unicode was concerned with ensuring lossless round-tripping.

It's sort of like the mess with Han Unification, but for different reasons. Turkish doesn't use a completely separate alphabet like Cyrillic, it's just an extended Latin alphabet like you'd find in various other European languages (eg. æ, ø, þ, ß, and so on.) but with the addition that the case-conversion rules for the common ASCII subset no longer hold true.

If installing Turkish locales for test purposes wasn't still on my TODO list, I'd post an example Python one-liner that behaves differently for the same ASCII I and i if you alter the LANG and LC_ environment variables.