On 11/01/19 16:06, Eli Zaretskii wrote: > The simple test program below almost always fails on my system. > "Almost always" means that it succeeds to create and open a temporary > file once every 6 invocations, on the average, and fails for all the > rest. When it fails, the value of errno is mostly EINVAL, but on a > couple of occasions I saw ENOENT. > > If I step with a debugger into __mingw_mkstemp, I see that > __mingw_crypto_tmpname in most cases generates a file name that is > invalid on Windows filesystems: it includes characters whose value is > below 32, Which isn't *supposed* to happen; the six 'X' chars, at the end of the template, are supposed to be replaced by random choices from within the regex pattern [0-9a-z]. > This is with the latest MinGW runtime 5.2 on a Windows XP system, with > MinGW GCC 7.3.0 and Binutils 2.31.1. > > Did I miss something obvious, or is this a real bug? Thanks. It is a real bug, introduced in mingwrt-5.2, while attempting to avoid a char * vs. unsigned char * type mismatch warning; the simplest change was, unfortunately, the wrong choice. The attached patch should fix it. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: mkstemp-file-name-generator.patch Type: text/x-patch Size: 2277 bytes Desc: not available URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190111/0d7a71c3/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190111/0d7a71c3/attachment.sig>
Fork