Concerns regarding fl_filename_ext()

[lifeatt...@gmail.com]

I've run into two issues with fl_filename_ext(). Using the latest github FLTK and Linux.

First, the documentation says the function returns NULL if there is no "last period". In fact, I've found the function returns the empty string in that case:

  out = fl_filename_ext("/some/path/foo/");

  assert(out != 0);

  assert(strlen(out) == 0);

     

  out = fl_filename_ext("/some/path/foo");

  assert(out != 0);

  assert(strlen(out) == 0);

This appears to be day-zero behavior, so a minor tweak to the documentation should be all that is required.

Second, how is a hidden file/folder expected to be handled? E.g.

  out = fl_filename_ext("/some/path/foo/.hidden");

will return the string ".hidden", whereas I consider the path to not have an extension.

Any thoughts?

Kevin

[Bill Spitzak]

The behavior with /.hidden could probably be changed to match Unix conventions. Look for the last period that is at least 2 places beyond the last slash.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/d07d812f-0830-4d20-ac6a-8522afec9ff9n%40googlegroups.com.

[Albrecht Schlosser]

On 4/24/21 8:47 PM lifeatt...@gmail.com wrote:
> I've run into two issues with fl_filename_ext(). Using the latest github
> FLTK and Linux.
>
> First, the documentation says the function returns NULL if there is no
> "last period". In fact, I've found the function returns the empty string
> in that case:
>
>   out = fl_filename_ext("/some/path/foo/");
>   assert(out != 0);
>   assert(strlen(out) == 0);
>   out = fl_filename_ext("/some/path/foo");
>   assert(out != 0);
>   assert(strlen(out) == 0);
>
> This appears to be day-zero behavior, so a minor tweak to the
> documentation should be all that is required.

I agree, if this is indeed day-zero behavior, then the docs could be
fixed, but OTOH returning NULL seems more appropriate (to me).

> Second, how is a hidden file/folder expected to be handled? E.g.
>
>   out = fl_filename_ext("/some/path/foo/.hidden");
>
> will return the string ".hidden", whereas I consider the path to not
> have an extension.
>
> Any thoughts?

First of all, what is a "hidden" file, or, a better question would be:
"on which platform(s) is a filename or directory-name beginning with '.'
considered a hidden file?

I know it's a Unix convention, but what about Windows? I don't think
it's a general convention on Windows because Windows has its own
"hidden" file attribute. OTOH, if you're using a POSIX shell like MinGW,
MSYS, etc. then the Unix convention would be valid. However, FLTK is not
a shell, so which convention should be used?

I don't have clear answers to all these questions.

Second, I agree that the Unix convention as described by Bill would be
good to use *if* we changed the code.

[lifeatt...@gmail.com]

>I agree, if this is indeed day-zero behavior, then the docs could be
>fixed, but OTOH returning NULL seems more appropriate (to me).

That is up to you guys. As a library maintainer in the past, I was taught that introducing breaking changes was a no-no.

Changing the docs instead of the code avoids having to check the 5 places in the FLTK codebase where the function is used [and where several calls assume that strcmp will not fall over when passed NULL].

>First of all, what is a "hidden" file, or, a better question would be:

Then I shouldn't have mentioned that part - my question is merely whether the file/folder ".somefile" has an extension or not. Or "." and ".." : both of whom return "." from the function.

This is kinda a naming debate - the function is named "fl_filename_ext" which implies that it returns the extension portion of the filename, as defined by the platform rules. However, the implementation returns the portion of the path from the last period onward, which might not be the same thing?

Kevin

[Bill Spitzak]

Returning nullptr is a very bad idea, as almost any calling code will have to test for this, usually to change it right back to "".

Returning "" (actually the nul at the end of the filename) if there is no extension, and returning starting from the period if there is one, is the original design and was always intended. This was so the offset into the filename was where the period would be written if you wanted to change the extension.

I agree it would be best to fix it to ignore any period before the first non-period after the last slash, so that ".hidden" and ".." and so on act like they have no extension.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/4a94e266-942d-4991-afa7-41580004fad5n%40googlegroups.com.

[Albrecht Schlosser]

On 4/26/21 9:38 PM Bill Spitzak wrote:
> Returning nullptr is a very bad idea, as almost any calling code will
> have to test for this, usually to change it right back to "".

Okay...

> Returning "" (actually the nul at the end of the filename) if there is
> no extension, and returning starting from the period if there is one, is
> the original design and was always intended. This was so the offset into
> the filename was where the period would be written if you wanted to
> change the extension.

Understood. Thanks for the clarification.

Then we should really update the docs.

> I agree it would be best to fix it to ignore any period before the first
> non-period after the last slash, so that ".hidden" and ".." and so on
> act like they have no extension.

Yep, and that would then also be platform independent.