1. Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 03, 2007
- 481 views
I was testing a program and needed to add the following folder to EUDIR: D:\YKNUHW\Privé\telech\win32lib_v006006\Include (the last character of Priv? is a e with acute accent). Rebooted, file not found. And yet it was there. For safety, I copied the path from Explorer to the environment variable editor, so as to avoid any typo issue. To no avail. I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed the environment variable accordingly. Rebooted, file now found. So, it looks like include paths with accented characters, which are completely allowed and useful under Windows, are not searched correctly. My guess is that the case insensitive search mechanism, which uses upper(), doesn't work right for at least some accented chars, but have no time to investigate further right now. Any quick fix? RDS: any chance to get this fixed? CChris
2. Re: Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 03, 2007
- 461 views
CChris wrote: > > > I was testing a program and needed to add the following folder to EUDIR: > D:\YKNUHW\Privé\telech\win32lib_v006006\Include > (the last character of Priv? is a e with acute accent). > Rebooted, file not found. And yet it was there. > For safety, I copied the path from Explorer to the environment variable > editor, so as to avoid any typo issue. To no avail. > I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed > the environment variable accordingly. > Rebooted, file now found. > > So, it looks like include paths with accented characters, which are > completely allowed and useful under Windows, are not searched correctly. > > My guess is that the case insensitive search mechanism, which uses upper(), > > doesn't work right for at least some accented chars, but have no time to > investigate further right now. > Any quick fix? > RDS: any chance to get this fixed? > > CChris Note that, if I replace, in the tested file, the file name by its full quoted path (hence not relying on EUDIR), then the file is found in spite of the accented letter in the path. CChris
3. Re: Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 03, 2007
- 478 views
CChris wrote: > > CChris wrote: > > > > > > I was testing a program and needed to add the following folder to EUDIR: > > D:\YKNUHW\Privé\telech\win32lib_v006006\Include > > (the last character of Priv? is a e with acute accent). > > Rebooted, file not found. And yet it was there. > > For safety, I copied the path from Explorer to the environment variable > > editor, so as to avoid any typo issue. To no avail. > > I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed > > the environment variable accordingly. > > Rebooted, file now found. > > > > So, it looks like include paths with accented characters, which are > > completely allowed and useful under Windows, are not searched correctly. > > > > My guess is that the case insensitive search mechanism, which uses upper(), > > > > doesn't work right for at least some accented chars, but have no time to > > investigate further right now. > > Any quick fix? > > RDS: any chance to get this fixed? > > > > CChris > > Note that, if I replace, in the tested file, the file name by its full > quoted path (hence not relying on EUDIR), then the file is found in spite > of the accented letter in the path. > > CChris After digging a little, I can see that upper() isn't the problem. The issue is with the different encodings of accented characters in various fonts. Indeed, when I use an absolute path (succesful), the path which is tried out by path_open() has a #E9 in it, while the environment variable that
getenv()
returns has a #82 in it, resulting in a failure to locate the file. When an accented character occurs in any of the folders listed in EUINC (and not EUDIR ), shouldn't path_open() try different font mappings? The font used when editing a variable under XP can be assessed, and no variable can be set from autoexec.bat, so that there should not be too many encodings to try. CChris
4. Re: Bug in Eu v3.0.2 include system (Wincows XP Pro, french)
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Apr 03, 2007
- 466 views
CChris wrote: > > > I was testing a program and needed to add the following folder to EUDIR: > D:\YKNUHW\Privé\telech\win32lib_v006006\Include > (the last character of Priv? is a e with acute accent). > Rebooted, file not found. And yet it was there. > For safety, I copied the path from Explorer to the environment variable > editor, so as to avoid any typo issue. To no avail. > I copied the folder to D:\YKNUHW\win32lib_v006006\Include and changed > the environment variable accordingly. > Rebooted, file now found. > > So, it looks like include paths with accented characters, which are > completely allowed and useful under Windows, are not searched correctly. > > My guess is that the case insensitive search mechanism, which uses upper(), > > doesn't work right for at least some accented chars, but have no time to > investigate further right now. > Any quick fix? > RDS: any chance to get this fixed? > > CChris Ok, U'm getting somewhere, but still, there is a bug. Howver, the bug is in getenv(). Windows XP (don't know if this holds for earlier versions) stores data as Unicode. However, getenv() returns data which is encoded using the current OEM code page (437 or 850 exhibit the same behaviour). As a result, the string getenv() returns is intermreted by Windows as Unicode even though it is encoded using the 437/850 code page. As a result, getenv(), on XP at least, should translate the environment string back to Unicode for it to be correctly understood by the OS. The workaround I found is to look up the UTF-16 for the character I know the OEM encoding of, then go to environment editor and paste the character which has that Unicode encoding in the OEM code page. For instance, é has OEM code #82 and UTF-16 #E9. So I had to paste in the char whose OEM code is #E9 (which is Ú). After reboot, everything was working as expected. But this is really an annoyance, and one shouldn't need to tinker with environment variables like this. CChris