On 4/19/20, David Kastrup <d...@gnu.org> wrote: > mkstemp! does not generate a string. It overwrites an existing string > in-place, and that's bad news for a literal string.
Yes, it overwrite the string, opens a port, then I read the port-filename which should be an _other_ string object, shouldn’t it? (sigh -- _none_ of this would happen if they hadn’t decided to remove tmpnam, or if they had bothered to make tmpnam behave correctly and respect TMPDIR, or if they had a mkdtemp! function.) > At any rate, you don't write, as the comment states, in a "tmp > directory" but rather in the current directory. If you want a tmp > directory, you need to add it to the path. Yes. I thought mkstemp! was located in the TMPDIR directory (as they state in their latest documentation, which is even invoked as the rationale for deprecating tmpnam). Turns out it’s merely created in the cwd, which isn’t nearly as clean. And I am reluctant to use mkstemp! "tmp/foobar-XXXXXX" because that would make it OS-non-agnostic. > And the .uuid file thing is a real problem with some versions of > fontconfig, so I lean to reverting the patch for now. Unless there is a way to make it safe for all versions and setups. (After all, I can test for that .uuid file and delete it if found, or rm -rf the subdirectory as I said.) By the way, since you’ve showed us yours, here’s mine: $: fc-scan --version fontconfig version 2.13.92 V.
