Re: Relocatable: relocate2

[Bruno Haible]

Hi Reuben,

> I noticed relocate2 recently. Unfortunately, it's rather awkward to use, as
> it requires one to keep track of two pointers.

The idiom is:

        char *allocated;
        const char *rel_pathname = relocate2 (..., &allocated);
        ...
        free (allocated);

This is the minimum awkwardness I could come up with.

> The obvious "lazy" API for code that doesn't mind allocation is for the
> relocated path always to be allocated. Would a patch to add such a version
> of relocate (suggestions for name?) be acceptable? It would work exactly
> like relocate, but strdup its return value if necessary.

1) I'm generally not a fan of APIs that call strdup without need. I've seen
C++ projects where the axiom "every memory-allocated object must have one
owner" led to an API where every API function that takes a char* or char[]
as argument makes a local copy of this argument. In the end, a large part
of the CPU consumption was due to making and freeing copies of strings.
This is generally the bad approach. The right approach is to share strings
when you can - possibly by use of reference counters if ad-hoc code does
not scale.

2) strdup can fail. When the programmer has to write

        char *rel_pathname = relocate_alloc (...);
        if (rel_pathname != NULL)
          {
            ...
            free (rel_pathname);
          }

the code is awkward as well.

Bruno