> By the way... according to MSDN page for CreateProcess() function > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx>: > "The maximum length of [the command line] is 32,768 characters, including the > Unicode terminating null character". > > UTF-8 uses up to 4 bytes for a character, so the maximum length of > a temporary buffer for a call like > > flac_fprintf(stderr, "%s: ERROR: couldn't get block from chain\n", > filename); > > should in theory exceed 4*32768 = 131072 bytes (plus some space for > the rest of the message). > > Currently *printf_utf8() functions allocate 32768 bytes buffer.
More info (see also <http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx>): A file path is limited by 260 characters. But WINAPI also supports an extended-length path (it has "\\?\" prefix) which is limited by 32767 unicode characters: \\?\c:\path\to\filename.ext FLAC uses __wgetmainargs to obtain Unicode command line arguments. This function can also expand wildcards. But in this case it converts "\\?\c:\path\to\filename.ext" into just "\\filename.ext" (looks like a bug in MS code). So currently FLAC doesn't support very long paths. Disabling of wildcards expansion fixes this, and FLAC will be able to en- and decode files with an extended-length path. (what do you prefer: wildcards expansion OR extended-length path support?) ...On the other hand, _wstat64 function in MSVC runtime doesn't like '?' inside paths, and as a result grabbag__file_get_filesize() returns -1. So disabling of wildcards expansion will not result in 100% support of long file paths in FLAC. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev