Re: [AD] al_path_set_extension

[Peter Wang <novalazy@xxxxxxxxxx>]

On 2009-02-13, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> On February 13, 2009, Peter Wang wrote:
> > Further path questions:
> >
> > 1. Is it important to allow NULL drive and filename components?  Is
> > there any difference between a NULL drive/filename and a drive/filename
> > which is an empty string?  It is easier for the implementation if we
> > don't use NULLs internally.
> 
> It may clean things up a bit, but currently iirc, the code generates both in a 
> somewhat messy way depending on platform and the component. I found it easier 
> to just allow NULL. But I wouldn't hurt to clean it up to fix "empty" drives 
> and filenames to be an empty string.

Using the new UTF-8 routines it's substantially easier if we never have
to think about maintaining the distinction between NULL and empty
strings.

> > 2. Can I change al_path_get_extension and al_path_get_basename to return
> > pointers to internally allocated memory, instead of filling a buffer
> > provided by the user?  This is consistent with al_path_get_drive,
> > al_path_get_index, al_path_get_filename, and easier to use.  It's only a
> > little bit of extra memory to copy the basename from the filename when
> > the user calls al_path_get_basename.
> >
> > 3. Similarly for al_path_to_string.
> 
> I'd prefer everything be fast AND thread safe to be honest. The functions that 
> don't fill in a user buffer are me just being lazy*. Returning a private 
> buffer makes it non thread safe,

It's already not thread safe.  If you allow two threads to work with the
same ALLEGRO_PATH object you need to synchronise yourself.

> unless you use TLS, but then it gets somewhat 
> slower. And returning a malloc buffer makes the user keep track of the memory. 

Not at all.  The allocated buffer would be tracked within the
ALLEGRO_PATH object, just like the drive, directory components, and the
file name, and it would be destroyed along with the rest of the object.
The description for al_path_to_string() would be like this:

    Get the string representation of a path.  The returned pointer is
    valid until the path is modified, or the path is destroyed.

If you want to copy it to a separate buffer, of course you can do that.

Most usages of path objects will be simply:

    ALLEGRO_PATH p = al_path_create(foo);
    manipulate p a bit
    f = fopen(al_path_to_string(p, '/'), "r");
    ...
    al_path_free(p);

as opposed to

    char buf[512];
    ALLEGRO_PATH p = al_path_create(foo);
    manipulate p a bit
    f = fopen(al_path_to_string(p, buf, sizeof(buf), '/'), "r");
    ...
    al_path_free(p);

where the arbitrary size of buf is likely to cause fopen to fail at some point.

> * And that those specific strings are ok to just return since they already 
> exist in the struct. al_path_to_string's result and the extension don't exist 
> by them selves, so a new buffer is required.

The extension actually does exist, as part of the file name.  But this
is premature optimisation.  In fact, I expect that the user is likely to
allocate a temporary buffer which takes way up more space than we'd
allocate in the path object, since we know exactly know much is
required, whereas the user has to make a safe guess.

Peter