1

I have a large amount of existing C++ code that uses plain fopen() in various places to open files. Generally, the path used is an absolute path, and starts either with "C:\Program Files (x86)\MyProgram..." or with "C:\Users\Public\MyProgramData...".

The program and data are installed to these locations by a standard installer (InnoSetup).

("C:\Program Files (x86)" and "C:\Users\Public" are not hard-coded in the code. But those are the suggested program and data install locations, so most often those will be the paths where files are opened, as created by the installer presumably in whatever local name those folders should have on the user's machine.)

I'm concerned about the possibility that on a non-English version of Windows, these path prefixes may contain non-ascii characters, which will make fopen() unhappy.

For "Program Files", the following references make it seem like my only potential worry among the most common languages is Hungarian ("Programfájlok"):

For "Users\Public" I was not able to find a reference giving translations for common languages like that, but in Spanish, for instance, I imagine it must be Pública?

Do you know what pitfalls I'm likely to encounter around the world using plain fopen() like this on these two paths?

M Katz
  • 5,098
  • 3
  • 44
  • 66

1 Answers1

3

use _wfopen which takes unicode paths.

https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx

corn3lius
  • 4,857
  • 2
  • 31
  • 36
  • As I said in the question, I have a large amount of code that already uses fopen(). I know I could convert it to _wfopen(). But it's a risk to change the code at this time, so I'm trying to assess the risk if I leave the code as-is. – M Katz Jan 22 '15 at 04:02
  • No where in your question does it mention you knew about `_wfopen` and unicode (Wide Char) support.... I had personally a lot of issues with unicode file names and non Unicode file handling. I had to refactor > 50K line code base to account for strcpy /strcmp etc. – corn3lius Jan 22 '15 at 17:42