github-starred/libxlsxwriter

Fork 0

mirror of https://github.com/jmcnamara/libxlsxwriter.git synced 2026-05-15 14:15:54 -06:00

[GH-ISSUE #104] MultiByteToWideChar breaks file name #85

New issue

Closed

opened 2026-05-05 11:38:09 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 11:38:09 -06:00

Owner

Originally created by @kubajar on GitHub (Apr 25, 2017).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/104

Originally assigned to: @jmcnamara on GitHub.

lxw_workbook *workbook = workbook_new("filename.xlsx"); saves f instead of filename.xlsx.

Small fix in packager.c in line 62 fixes filename for me (program saves filename.xlsx): .

-     return zipOpen2_64(wide_filename, 0, NULL, &filefunc);
+     return zipOpen2_64(filename,      0, NULL, &filefunc);

tested on latest trunk + Visual Studio 2010.

have a nice day.

Originally created by @kubajar on GitHub (Apr 25, 2017). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/104 Originally assigned to: @jmcnamara on GitHub. lxw_workbook *workbook = workbook_new("filename.xlsx"); saves f instead of filename.xlsx. Small fix in [packager.c in line 62](https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L62) fixes filename for me (program saves filename.xlsx): . ```diff - return zipOpen2_64(wide_filename, 0, NULL, &filefunc); + return zipOpen2_64(filename, 0, NULL, &filefunc); ``` tested on latest trunk + Visual Studio 2010. have a nice day.

gitea-mirror

2026-05-05 11:38:09 -06:00

closed this issue
added the
question
label

gitea-mirror commented

2026-05-05 11:38:15 -06:00

Author

Owner

@jmcnamara commented on GitHub (Apr 26, 2017):

I haven't had any other bug reports of that nature and that Windows code is used quite a lot.

Also, I don't see any issue with MSVC 2015. Is this just an issue with MSVC 2010.

@utelle, as the resident Windows expert, could you have a quick look at this to see if there is an issue?

@jmcnamara commented on GitHub (Apr 26, 2017): I haven't had any other bug reports of that nature and that Windows code is used quite a lot. Also, I don't see any issue with MSVC 2015. Is this just an issue with MSVC 2010. @utelle, as the resident Windows expert, could you have a quick look at this to see if there is an issue?

gitea-mirror commented

2026-05-05 11:38:18 -06:00

Author

Owner

@utelle commented on GitHub (Apr 26, 2017):

I use libxlsxwriter in a 32-bit Windows application compiled with MSVC 2010. Up to now neither the users of my application nor I myself had any issues with it.

However, it might depend on compiler settings. The filename parameter is passed as const void*. Down the line this is casted to LPCTSTR in function win32_open64_file_func (iowin32.c).

The type LPCTSTR is defined as

LPCTSTR = const char* or const wchar_t* depending on _UNICODE

So, if the symbol _UNICODE is not defined, this would result in a cast to const char*. And this could indeed explain the problem @kubajar experienced.

The premake4 script coming with libxlsxwriter defines the Unicode flag. However, if premake4 was not used to generate the build files, the Unicode flag might be missing.

@utelle commented on GitHub (Apr 26, 2017): I use `libxlsxwriter` in a 32-bit Windows application compiled with MSVC 2010. Up to now neither the users of my application nor I myself had any issues with it. However, it might depend on compiler settings. The filename parameter is passed as `const void*`. Down the line this is casted to `LPCTSTR` in function `win32_open64_file_func` (iowin32.c). The type `LPCTSTR ` is defined as ``` LPCTSTR = const char* or const wchar_t* depending on _UNICODE ``` So, if the symbol `_UNICODE` is not defined, this would result in a cast to `const char*`. And this could indeed explain the problem @kubajar experienced. The `premake4` script coming with `libxlsxwriter` defines the `Unicode` flag. However, if `premake4` was not used to generate the build files, the `Unicode` flag might be missing.

gitea-mirror commented

2026-05-05 11:38:21 -06:00

Author

Owner

@kubajar commented on GitHub (Apr 26, 2017):

/D "_UNICODE" /D "UNICODE" is present in command line. I used cmake for makefile generation, maybe there is some issue. Tested both Unicode and multibyte character sets. It must be something unicode-specific, like in code (unicode character set):

#include <stdio.h>
#include <tchar.h>
int _tmain(int argc, _TCHAR* argv[]) //test.exe
{
	printf("%s\n", argv[0]); //prints t
	printf("%ls\n", argv[0]); //prints test
	return 0;
}

@kubajar commented on GitHub (Apr 26, 2017): ` /D "_UNICODE" /D "UNICODE"` is present in command line. I used cmake for makefile generation, maybe there is some issue. Tested both Unicode and multibyte character sets. It must be something unicode-specific, like in code (unicode character set): ```C #include <stdio.h> #include <tchar.h> int _tmain(int argc, _TCHAR* argv[]) //test.exe { printf("%s\n", argv[0]); //prints t printf("%ls\n", argv[0]); //prints test return 0; } ```

gitea-mirror commented

2026-05-05 11:38:24 -06:00

Author

Owner

@utelle commented on GitHub (Apr 26, 2017):

You will have to verify that all libxlsxwriter source files are really compiled with the Unicode symbols. libxlsxwriter always converts the filename to wide string. Thus, for your filename filename.xlsx the memory contains the bytes 'f' followed by '\0' followed by 'i' followed by '\0' and so on. If casted to const char* you therefore get the filename f due to the zero byte.

Obviously the wrong cast is applied in your case.

I would recommend to use the Visual Studio debugger to step through the relevant code and find out, where exactly the wrong cast is applied.

@utelle commented on GitHub (Apr 26, 2017): You will have to verify that all `libxlsxwriter` source files are really compiled with the Unicode symbols. `libxlsxwriter` always converts the filename to wide string. Thus, for your filename `filename.xlsx` the memory contains the bytes `'f'` followed by `'\0'` followed by `'i'` followed by `'\0'` and so on. If casted to `const char*` you therefore get the filename `f` due to the zero byte. Obviously the wrong cast is applied in your case. I would recommend to use the Visual Studio debugger to step through the relevant code and find out, where exactly the wrong cast is applied.

gitea-mirror commented

2026-05-05 11:38:25 -06:00

Author

Owner

@kubajar commented on GitHub (Apr 26, 2017):

I found the problem - I compilled zlib and zlibwapi as multibyte. I switched character set to unicode and all works perfectly. Thank You for great software and help. Have a nice day.

@kubajar commented on GitHub (Apr 26, 2017): I found the problem - I compilled zlib and zlibwapi as multibyte. I switched character set to unicode and all works perfectly. Thank You for great software and help. Have a nice day.

gitea-mirror commented

2026-05-05 11:38:28 -06:00

Author

Owner

@jmcnamara commented on GitHub (Apr 26, 2017):

@kubajar Thanks for the update and @utelle thanks for the help. Closing.

@kubajar for reference could you add the commands you used to build with cmake.

@jmcnamara commented on GitHub (Apr 26, 2017): @kubajar Thanks for the update and @utelle thanks for the help. Closing. @kubajar for reference could you add the commands you used to build with cmake.