Re: [AD] al_path_set_extension

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On February 13, 2009, Peter Wang wrote:
> On 2009-02-13, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > On February 13, 2009, Trent Gamblin wrote:
> > > On Fri, February 13, 2009 6:00 pm, Peter Wang said:
> > > > One way to resolve this is to define an extension to include the dot
> > > > as well.  Then:
> > > >
> > > >     al_path_set_extension("abc", ".ext")     ==> "abc.ext"
> > > >     al_path_set_extension("abc.ext", ".def") ==> "abc.def"
> > > >     al_path_set_extension("abc.def", "")     ==> "abc"
> > > >
> > > > Then al_path_set_extension could be used to remove the extension. 
> > > > Also the first call doesn't magically grow a dot character out of
> > > > nowhere. al_path_get_extension would return the leading dot.
> > > >
> > > > What do you think?
> > >
> > > Better than the current behaviour.
> >
> > So long as it makes sense, I don't much care.
>
> 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.

> 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, unless you use TLS, but then it gets somewhat 
slower. And returning a malloc buffer makes the user keep track of the memory. 
I figured if the user REALLY wanted to keep track of the memory, they could 
malloc it themselves and pass it into the function.

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

> 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