On 2025-01-04 Pali Rohár wrote:
> Interesting... What is not clear is if the research team reported this
> bug to Microsoft and if Microsoft is going to address this issue at
> some level, or at least document best practices what should affected
> applications do.
There is a blog post with more details:
https://devco.re/blog/2025/01/09/worstfit-unveiling-hidden-transformers-in-windows-ansi/
According to that, Microsoft knows this. The addition to the
GetCommandLineA docs is mentioned. Only time will tell if more will
come but I don't know how long it makes sense to wait.
MinGW-w64's <dirent.h> is affected too. One fix could be to skip over
problematic filenames but remember that such skipping has occurred.
Then, after the last filename in the directory, return an error. This
way one would list all filenames that can be listed. On the other hand,
fast error detection is better in some use cases.
According to POSIX, the correct errno value would be EOVERFLOW: "One of
the values in the structure to be returned cannot be represented
correctly."
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/readdir_r.html
If a 8.3 name is available, it could be returned instead but I fear it
creates more issues than solves. For example, copying files with a
wrong tool would result in loss of the long names like in 1990s. As
always, the least bad choice depends on what exactly the application is
doing with the filenames.
Can the structs in MinGW-w64's <dirent.h> be changed or are they all
part of the ABI that shouldn't be broken? In struct dirent, extending
"char d_name[260];" would allow long UTF-8 filenames to fit.
--
Lasse Collin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
