Re: There are still bugs in dirname(3) (glibc 2.2.3.pre1)

[Michael Kerrisk]

> "Michael Kerrisk" <address@hidden> writes:
> 
> |> Gidday,
> |> 
> |> A while back I submitted a patch for dirname(3) for glibc 2.2.1, which  
> was 
> |> not correctly handling the case of trailing slashes in pathnames. The 
> |> version is glibc 2.2.3pre1 is improved, but still broken.  SUSv2 says 
> |> 
> |>         "Trailing '/' character**s** in the path are not counted as 
> |>         part of the path"  
> |> 
> |> Note the plural!  (As usual for Unix pathnames, repeated slashes are 
> |> equivalent to a single slash). Thus the 2.2.3pre1 version of 
dirname(3), 
> |> given the following paths: 
> |> 
> |>  > returns      Should return 
> |> a//       a                . 
> |> a////     a//              . 
> |> ////a     ///              /
> 
> Note that // at the *beginning* of a filename is still special and must be
> preserved.

Hello Andreas,

Thanks for your note.  But,I'm not sure whether this is true And am open 
to correction!).  First of all, SUSv2 and Austin draft 5 say that for the 
dirname(1) *command*, then repeated slashes at the start of the pathname 
may or may not be preserved (implementation dependent).  Thus, "dirname 
//" can return '/' or '//'.  (Linux dirname(1), which I assume comes from 
FSF, does not preserve excess slashes, so that e.g., "dirname //a" gives 
'/').  

However, for the dirname(3) *function*, no mention is made of this 
requirement in SUSv2 or Austin d5.

Cheers

Michael

__________________________________________
Michael Kerrisk
mailto: address@hidden

"Marx: Nice try, but MacDonalds won"