#11057 closed Patch (rejected)
String conversion functions failure
| Reported by: | Paolo Zambotti | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | libfilezilla |
| Keywords: | string conversion wcsrtombs mbsrtowcs | Cc: | |
| Component version: | trunk | Operating system type: | Windows |
| Operating system version: | 10 |
Description
Some compilers (eg. mingw) library functions (surely wcsrtombs and, I guess, mbsrtowcs too) fail if the destination buffer size is 0, even if the destination pointer is NULL. In this case (NULL pointer) the function(s) returns the minimum between the real
string length and the destination buffer size. So, if the destination size is 0, the return value is always 0.
The attached patch turns the size parameter to -1 (this is a trick to set all the bits to 1 regardless of the parameter type) where the pointer is NULL.
I see this issue only when behind proxy with ASCII character support only.
Attachments (1)
Change History (3)
comment:1 by , 8 years ago
| Component: | FileZilla Client → libfilezilla |
|---|
comment:2 by , 8 years ago
| Resolution: | → rejected |
|---|---|
| Status: | new → closed |
Wrong place to fix. This is a bug in the C runtime in which it is not compliant to the C specifications and as such needs it is an issue that must be fixed upstream.
In case of the MinGW-w64 CRT I've already taken care of this: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/5689BA84.6040808%40filezilla-project.org/#msg34737707
If you are using the MinGW-w64 CRT you need to update your toolchain. If you are using a different runtime, contact your runtime vendor for assistance.
Note that the unit tests in libfilezilla specifically test for this kind of CRT bug.
changed wrong component assignment