Remove $FreeBSD$: two-line nroff pattern

Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/

Remove $FreeBSD$: two-line nroff pattern

Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/

Merge ^/head r318658 through r318963.

dirname(3): fix section ordering

IMPLEMENTATION NOTES come before RETURN VALUES

MFC after: 2 weeks
Reported by: make manlint
Sponsored by: Dell EMC Isilon

Merge ^/head r305892 through r306302.

Replace dirname(3) by a copy that complies to POSIX.

It turns out that the path normalization that our brand new copy of
dirname(3) does is actually not allowed by the draft version of the
upcoming

Replace dirname(3) by a copy that complies to POSIX.

It turns out that the path normalization that our brand new copy of
dirname(3) does is actually not allowed by the draft version of the
upcoming version of POSIX. It has to behave identically to the
dirname(1) utility.

This change replaces our new dirname(3) implementation by yet another
version that doesn't implement the path normalization logic; it merely
looks for the end of the directory name and overwrites that with a null
byte.

More details: See note #3370 at http://austingroupbugs.net/view.php?id=1073

PR: 212193
Reviewed by: emaste, jilles
Differential Revision: https://reviews.freebsd.org/D7790

show more ...

Merge ^/head r303250 through r304235.

MFhead @ r304038

Reimplement dirname(3) to be thread-safe.

Now that we've updated the prototypes of the basename(3) and dirname(3)
functions to conform to POSIX, let's go ahead and reimplement dirname(3)
in such a w

Reimplement dirname(3) to be thread-safe.

Now that we've updated the prototypes of the basename(3) and dirname(3)
functions to conform to POSIX, let's go ahead and reimplement dirname(3)
in such a way that it's thread-safe, but also guaranteed to succeed. C
libraries like glibc, musl and the one that's part of Solaris already
follow such an approach.

Move the existing implementation to another source file,
freebsd11_dirname.c to keep existing users of the API that pass in a
constant string happy, using symbol versioning.

Put a new version of the function in dirname.c, obtained from CloudABI's
C library. This version scans through the pathname string from left to
right, normalizing it, while discarding the last pathname component.

Reviewed by: emaste, jilles
Differential Revision: https://reviews.freebsd.org/D7355

show more ...

Mention that basename(3) and dirname(3) will change in the future.

Update the existing manual pages for basename(3) and dirname(3) to
mention that in future versions of FreeBSD, these functions will

Mention that basename(3) and dirname(3) will change in the future.

Update the existing manual pages for basename(3) and dirname(3) to
mention that in future versions of FreeBSD, these functions will no
longer use internal buffers for storing the results.

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D7356

show more ...

Fix up prototypes of basename(3) and dirname(3) to comply to POSIX.

POSIX allows these functions to be implemented in a way that the
resulting string is stored in the input buffer. Though some may f

Fix up prototypes of basename(3) and dirname(3) to comply to POSIX.

POSIX allows these functions to be implemented in a way that the
resulting string is stored in the input buffer. Though some may find
this annoying, this has the advantage that it makes it possible to
implement this function in a thread-safe way. It also means that they
can be implemented in a way that they work for paths of arbitrary
length, as the output string of these functions is never longer than
max(1, len(input)).

Portable code already needs to be written with this in mind, so in my
opinion it makes very little sense to allow the existing behaviour.
Prevent the base system from falling back to this by switching over to
POSIX prototypes.

I'm not going to bump the __FreeBSD_version for this. The reason is that
it's possible to account for this change in a portable way, without
depending on a specific version of FreeBSD. An exp-run was done some
time ago. As far as I know, all regressions as a result of this have
already been fixed.

I'll give this change some time to settle. In the long run I want to
replace our copies by ones that are thread-safe and don't depend on
PATH_MAX/MAXPATHLEN.

show more ...

Revert lib/libc/gen/dirname.3@r289695

This is why I use branches usually, not commit directly to head

Revert r289694

I committed some other undesirable local changes by accident

Merge ^/head r318658 through r318963.

dirname(3): fix section ordering

IMPLEMENTATION NOTES come before RETURN VALUES

MFC after: 2 weeks
Reported by: make manlint
Sponsored by: Dell EMC Isilon

Merge ^/head r305892 through r306302.

Replace dirname(3) by a copy that complies to POSIX.

It turns out that the path normalization that our brand new copy of
dirname(3) does is actually not allowed by the draft version of the
upcoming

Replace dirname(3) by a copy that complies to POSIX.

It turns out that the path normalization that our brand new copy of
dirname(3) does is actually not allowed by the draft version of the
upcoming version of POSIX. It has to behave identically to the
dirname(1) utility.

This change replaces our new dirname(3) implementation by yet another
version that doesn't implement the path normalization logic; it merely
looks for the end of the directory name and overwrites that with a null
byte.

More details: See note #3370 at http://austingroupbugs.net/view.php?id=1073

PR: 212193
Reviewed by: emaste, jilles
Differential Revision: https://reviews.freebsd.org/D7790

show more ...

Merge ^/head r303250 through r304235.

MFhead @ r304038

Reimplement dirname(3) to be thread-safe.

Now that we've updated the prototypes of the basename(3) and dirname(3)
functions to conform to POSIX, let's go ahead and reimplement dirname(3)
in such a w

Reimplement dirname(3) to be thread-safe.

Now that we've updated the prototypes of the basename(3) and dirname(3)
functions to conform to POSIX, let's go ahead and reimplement dirname(3)
in such a way that it's thread-safe, but also guaranteed to succeed. C
libraries like glibc, musl and the one that's part of Solaris already
follow such an approach.

Move the existing implementation to another source file,
freebsd11_dirname.c to keep existing users of the API that pass in a
constant string happy, using symbol versioning.

Put a new version of the function in dirname.c, obtained from CloudABI's
C library. This version scans through the pathname string from left to
right, normalizing it, while discarding the last pathname component.

Reviewed by: emaste, jilles
Differential Revision: https://reviews.freebsd.org/D7355

show more ...

Mention that basename(3) and dirname(3) will change in the future.

Update the existing manual pages for basename(3) and dirname(3) to
mention that in future versions of FreeBSD, these functions will

Mention that basename(3) and dirname(3) will change in the future.

Update the existing manual pages for basename(3) and dirname(3) to
mention that in future versions of FreeBSD, these functions will no
longer use internal buffers for storing the results.

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D7356

show more ...

Fix up prototypes of basename(3) and dirname(3) to comply to POSIX.

POSIX allows these functions to be implemented in a way that the
resulting string is stored in the input buffer. Though some may f

Fix up prototypes of basename(3) and dirname(3) to comply to POSIX.

POSIX allows these functions to be implemented in a way that the
resulting string is stored in the input buffer. Though some may find
this annoying, this has the advantage that it makes it possible to
implement this function in a thread-safe way. It also means that they
can be implemented in a way that they work for paths of arbitrary
length, as the output string of these functions is never longer than
max(1, len(input)).

Portable code already needs to be written with this in mind, so in my
opinion it makes very little sense to allow the existing behaviour.
Prevent the base system from falling back to this by switching over to
POSIX prototypes.

I'm not going to bump the __FreeBSD_version for this. The reason is that
it's possible to account for this change in a portable way, without
depending on a specific version of FreeBSD. An exp-run was done some
time ago. As far as I know, all regressions as a result of this have
already been fixed.

I'll give this change some time to settle. In the long run I want to
replace our copies by ones that are thread-safe and don't depend on
PATH_MAX/MAXPATHLEN.

show more ...

Revert lib/libc/gen/dirname.3@r289695

This is why I use branches usually, not commit directly to head

Revert r289694

I committed some other undesirable local changes by accident

integrate from head@185615