El 22/12/2025 a las 20:44, Andrey Semashev via Boost escribió:
But here is the question: do we actually want to consistently treat Cygwin as a POSIX platform across Boost libraries? In regards to Boost.Filesystem, I'm not sure what Cygwin runtime does with paths, as it eventually has to interact with the underlying Windows API. Does it perform character code conversion? Is that conversion correct? Which encoding does it expect?
I think Cygwin is, by definition, a Unix environment at we should treat it like that. ------------------------------ https://cygwin.com/cygwin-ug-net/setup-locale.html "The default locale in the absence of the aforementioned locale environment variables is "C.UTF-8". "Windows uses the UTF-16 charset exclusively to store the names of any object used by the Operating System. This is especially important with filenames. Cygwin uses the setting of the locale environment variables LC_ALL, LC_CTYPE, and LANG, to determine how to convert Windows filenames from their UTF-16 representation to the singlebyte or multibyte character set used by Cygwin." "The setting of the locale environment variables at process startup is effective for Cygwin's internal conversions to and from the Windows UTF-16 object names for the entire lifetime of the current process. Changing the environment variables to another value changes the way filenames are converted in subsequently started child processes, but not within the same process." ------------------------------ So IMHO Filesystem should treat Cygwin as any other Unix system. However, I understand that this breaks previous users. One option would be to offer a backwards compatibility macro switch to go back to the Windows API for those users that want to maintain backwards compatibility. That would require, however, more complicated maintenance (say, testing cygwin both as UNIX and Win32 platforms). Best, Ion