Re: Patchy email

[David Kastrup]

Valentin Villenave <address@hidden> writes:

> On 4/19/20, David Kastrup <address@hidden> 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