[Bf-committers] BLI_gzopen fails to open files with Unicode names in Windows when short path generation is disabled.

[Jason Wilkins]

If short path generation is disabled on Windows then if you open a
file that was created after short name generation was turned off the
function GetShortPathName will return the long name.  It may shorten
some of the folder names, but the file will still be the original long
name and that includes the potential for UTF16 characters outside of
the ANSI range.

The result is that a .blend file containing Unicode characters cannot
be opened by Blender in Windows if the user has disabled short file
name generation, has not generated a short name, and that file
contains a wide character.

The current BLI_gzopen assumes that GetShortPathName will give it a
path that contains only ANSI characters and uses a naive conversion of
just casting each short to char.  No where in any documentation did I
ever find a guarantee that GetShortPathName will return a string that
can be converted this way and it did not take much for me to break it.

So, I went to fix a warning and found a broken function.  I'm not sure
what to do however because I do not understand why GetShortPathName
was being used at all.  The closest I can come up with is that there
is an assumption that GetShortPathName will return a nice ANSI encoded
string that can be passed to gzopen.  Maybe gzopen does not support
UTF8?

If gzopen supported UTF8 then it seems like we could pass the filename
directly to gzopen without any of the calls to GetShortPathName or any
other encoding conversions.  But this function assumes it needs to be
more complicated (and gets it wrong) and there is no documentation as
to why.