Re: [AD] al_path_set_extension

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On February 14, 2009, Peter Wang wrote:
> 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.

PATH_MAX/MAX_PATH is likely to cause that at some point anyway.

> > * 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.

Do whatever you think is right.

> Peter
>
>
> ---------------------------------------------------------------------------
>--- Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing
> the Enterprise -Strategies to boost innovation and cut costs with open
> source participation -Receive a $600 discount off the registration fee with
> the source code: SFAD http://p.sf.net/sfu/XcvMzF8H


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx