new FreeBSD port maintainer

[Rich Felker]

On Sat, Sep 10, 2011 at 10:30:45PM +0200, Matthias Andree wrote:
> Am 10.09.2011 20:33, schrieb Laurent Bercot:
> >>> #if !defined __FreeBSD__
> >>> char *dirname(char *path);
> >>> #endif
> >>> Can you confirm that it helps?
> >> It's bogus because ours is const char *.
> > 
> >  FreeBSD defines dirname as a different function from the standard
> > and then *busybox* is bogus ?
> >  Please.
> > 
> >  This is the exact kind of bullshit incompatibilities that application
> > developers should not have to care about, ever. FreeBSD has no business
> > redefining dirname's prototype; if it's not char *dirname (char *),
> > it's not conformant, period.
> 
> FreeBSD's dirname is conforming.  Note:

No it is not. The standard specifies the prototype.

>  * Applications (busybox) have no business redeclaring library
>    functions.  Instead, they are supposed to include the corresponding
>    headers, dirname.h in this case.

False. 2.1.1 statement 4 reads:

"Provided that a function can be declared without reference to any
type defined in a header, it is also permissible to declare the
function explicitly and use it without including its associated
header."

POSIX explicitly blesses the practice of manually declaring the
functions you wish to use.

>  * POSIX conforming applications using dirname() need not be changed
>    for use with FreeBSD's dirname() implementation.

The following application is a strictly conforming POSIX application:

#define _POSIX_C_SOURCE 200809L
#include <libgen.h>
char *dirname(char *);
int main()
{
}

It will not compile on FreeBSD due to a BUG IN FREEBSD!

> FreeBSD waives the former and implements the latter.  And because it
> does not modify the string, it advertises so through its header by
> adding the const keyword.  The standard cannot do that because it
> permits modification of the string.

Implementation choices are irrelevant to the requirements on the
function signature.

Rich