Hi. Thanks for the patch. I will commit warning fixes soon (or you can do it). Concerning GetShortPathName, I know it is not best solution and it is already caused problem when creating a file. The problem (afaik) is that file descriptors aren't native to windows, so each compile (and each version of vc) supports it differently. As a result if zlib is compiled with vc9 and if you use vc10, application will crash. That said, we need to have zlib compiled for each complier with correct runtime. I didn't had time to get around to it.
When it is done, we can indeed use: gzdopen(_fileno(ufopen(file,mode)), mode); Best Regards, Alex. On Tue, Apr 3, 2012 at 11:23 PM, Jason Wilkins <[email protected]>wrote: > I think figured this out and submitted a possible fix to the patch tracker. > > On Tue, Apr 3, 2012 at 9:38 PM, Jason Wilkins <[email protected]> > wrote: > > 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. > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
