Valentin Villenave <valen...@villenave.net> writes: > 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,
You can/must not override a literal string. It's read-only. > opens a port, then I read the port-filename which should be an _other_ > string object, shouldn’t it? Why? At any rate, no problem with appending non-destructively to an existing string. > (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. Should be /tmp/foobar-XXXXXX anyway unless environment variable TMPDIR is set in which case you use that. >> 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.) Preparing a fixed patch is not precluded by reverting it. > By the way, since you’ve showed us yours, here’s mine: > $: fc-scan --version > fontconfig version 2.13.92 Ok, but at least now it's not the upcoming Ubuntu version. -- David Kastrup
