Re: Use `strsave()`, not `strdup()`.

[Ralph Corderoy]

Hi Ingo,

> If the intention of strsave() was to replace strdup(), then the
> correct implementation would have been
>
>       size_t sz = strlen(s) + 1;
>       char *p = malloc(sz);
>       if (p != NULL)
>               memcpy(p, s, sz);
>       return p:

An estrdup() would be:

    if (!s)
        abort();
    char *n = strdup(s);
    if (!n)
        abort();
    return n;

This is simpler to verify IMO.

- It explicitly checks for the source string being a null pointer
  because dereferencing null doesn't guarantee a crash on all platforms;
  on my first C compiler platform, it gave the contents of memory
  location 0.
- The abort()s would really write(2) to stderr first; Brandon's
  suggestion of fputs(3) wrongly assumes it won't allocate memory.
- It does rely on a strdup() being present, either naturally or through
  a local stand-in, but the advantage of doing so is to break
  comprehension down into two separate parts.
- By calling one standard-library function instead of three in the
  common path, it's easier for the compiler to provide better
  performance.
- And it avoids the size_t overflow when adding one.  ;-)

> I don't think real-world implementations [of printf] allocate memory
> if you refrain from relying on wide character to multibyte character
> conversions.  Why should they?

I've experienced several which allocate.  One example is to get a stdio
buffer to print to as it's the first print such.

>       if ((p = malloc(sz)) == NULL) {
>               perror(__progname);
>               exit(1);
>       }

I don't know what value sz has in that case.  Ideally, it would be
write(2)-nd.  At least abort(3) might capture it.

> The message
>
>   __progname: Cannot allocate memory
>
> contains all information the user needs.

This is incorrect.  What bit of progname?  What was it trying to do?
How much was it trying to allocate?  Is that a reasonable amount or some
silly high amount which suggests memory has been corrupted rather than a
faulty calculation.

> I think printing the names of source code files, the names of
> functions in the source code, or line numbers of call sites in source
> code files is bad practice.  Such information is totally irrelevant
> for normal users, it is confusing and distracting, and it just makes
> the program look as if it were written for nerds rather than for
> users.  It does not even help developers.

If a user can report
    glyph.c:42:estrdup failed: 31415 'foo bar xyzzy...'
to the list for a sporadic bug which they can't reliably reproduce then
it far more helpful than
    __progname: Cannot allocate memory

> Note that
>   fatal("strdup: %1", strerror(errno));
> would be pointless.  It is completely irrelevant for the user whether
> it was malloc(3) or strdup(3) or whatever other allocating function
> that failed.  All that matters is "Cannot allocate memory".

The user reports up.  It may be a one-shot chance.

-- 
Cheers, Ralph.