Re: svn commit: r336835 - head/lib/libc/gen
On Sun, Jul 29, 2018 at 12:45:23AM +0300, Konstantin Belousov wrote: > On Sat, Jul 28, 2018 at 01:59:16PM -0700, Conrad Meyer wrote: > > On Sat, Jul 28, 2018 at 1:32 PM, Konstantin Belousov > > wrote: > > > Our existing practice is to not provide an advise in the man pages > > > for the userspace code which would harm the portability or the standard > > > conformance. > > > > Perhaps, but you do not have to look beyond this manual page to find > > that such a practice, if it is even nominally applied, is not followed > > consistently. The remainder of the document spells the terminating > > value as plain "NULL." FreeBSD manual pages consistently refer to > > NULL as a pointer value. > > > > The Linux manual page spells the terminating value (char *)NULL and > > explicitly documents why. That is perhaps both pedantically correct > > and clear. I am amenable to such a change. > I do not see much difference between (char *)0 and (char *)NULL. Both > are better there, because both are correct. > > If you prefer (char *)NULL, please use it. > > > > > > I am not so sure about CheriBSD, for instance. > > > > I observe simply that CheriBSD is not FreeBSD and that CHERI is an > > exotic architecture. > We should not give an advise which breaks other architectures, even > if not included into the mainline repo. CheriBSD would be fine because FreeBSD uses (void *)0 for NULL. That said, C++ requires that NULL be a bare 0 or nullptr so (char *)NULL is likely the most portable. -- Brooks signature.asc Description: PGP signature
Re: svn commit: r336835 - head/lib/libc/gen
On Sat, Jul 28, 2018 at 01:59:16PM -0700, Conrad Meyer wrote: > On Sat, Jul 28, 2018 at 1:32 PM, Konstantin Belousov > wrote: > > Our existing practice is to not provide an advise in the man pages > > for the userspace code which would harm the portability or the standard > > conformance. > > Perhaps, but you do not have to look beyond this manual page to find > that such a practice, if it is even nominally applied, is not followed > consistently. The remainder of the document spells the terminating > value as plain "NULL." FreeBSD manual pages consistently refer to > NULL as a pointer value. > > The Linux manual page spells the terminating value (char *)NULL and > explicitly documents why. That is perhaps both pedantically correct > and clear. I am amenable to such a change. I do not see much difference between (char *)0 and (char *)NULL. Both are better there, because both are correct. If you prefer (char *)NULL, please use it. > > > I am not so sure about CheriBSD, for instance. > > I observe simply that CheriBSD is not FreeBSD and that CHERI is an > exotic architecture. We should not give an advise which breaks other architectures, even if not included into the mainline repo. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336835 - head/lib/libc/gen
On Sat, Jul 28, 2018 at 1:32 PM, Konstantin Belousov wrote: > Our existing practice is to not provide an advise in the man pages > for the userspace code which would harm the portability or the standard > conformance. Perhaps, but you do not have to look beyond this manual page to find that such a practice, if it is even nominally applied, is not followed consistently. The remainder of the document spells the terminating value as plain "NULL." FreeBSD manual pages consistently refer to NULL as a pointer value. The Linux manual page spells the terminating value (char *)NULL and explicitly documents why. That is perhaps both pedantically correct and clear. I am amenable to such a change. > I am not so sure about CheriBSD, for instance. I observe simply that CheriBSD is not FreeBSD and that CHERI is an exotic architecture. Best, Conrad ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336835 - head/lib/libc/gen
On Sat, Jul 28, 2018 at 01:16:45PM -0700, Conrad Meyer wrote: > On Sat, Jul 28, 2018 at 1:06 PM, Konstantin Belousov > wrote: > > On Sat, Jul 28, 2018 at 07:08:00PM +, Conrad Meyer wrote: > >> For unclear reasons, POSIX' definition of these routines spells NULL as > >> "(char *)0." This is needlessly unclear. One guess might be that POSIX > >> targets more exotic computer architectures than FreeBSD does. > >> Fortunately, > >> there is no such problem on any reasonable platform for FreeBSD to > >> support. > >> Spell NULL as NULL. > > > > The reasons are quite clear. > > Unclear here refers to the lack of documentation, not the absense of a > possible explanation. > > > Practically NULL has to be defined as '0' > > or '0L' at best, for C and esp. C++ rules of the pointers automatic > > casts to work. This means that NULL cannot be used in vararg lists where > > the pointer is expected. > > This is not true on FreeBSD. NULL is (void*)0 in all C code, and the > special nullptr value in C++. Yes, this is a stronger definition than > the C standard guarantees. This is because the C standard permits > much more exotic architectures than FreeBSD actually runs on. Our existing practice is to not provide an advise in the man pages for the userspace code which would harm the portability or the standard conformance. > > > In other words, the (char *)0 part of the pre-commit text was correct, > > while after-commit use of NULL only works on machines where pointers > > have the same representation as ints or longs. > > I believe this encompasses all architectures FreeBSD supports ??? even > ignoring our sys/_null.h definition of NULL as (void *)0 or nullptr. I am not so sure about CheriBSD, for instance. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336835 - head/lib/libc/gen
On Sat, Jul 28, 2018 at 1:06 PM, Konstantin Belousov wrote: > On Sat, Jul 28, 2018 at 07:08:00PM +, Conrad Meyer wrote: >> For unclear reasons, POSIX' definition of these routines spells NULL as >> "(char *)0." This is needlessly unclear. One guess might be that POSIX >> targets more exotic computer architectures than FreeBSD does. Fortunately, >> there is no such problem on any reasonable platform for FreeBSD to support. >> Spell NULL as NULL. > > The reasons are quite clear. Unclear here refers to the lack of documentation, not the absense of a possible explanation. > Practically NULL has to be defined as '0' > or '0L' at best, for C and esp. C++ rules of the pointers automatic > casts to work. This means that NULL cannot be used in vararg lists where > the pointer is expected. This is not true on FreeBSD. NULL is (void*)0 in all C code, and the special nullptr value in C++. Yes, this is a stronger definition than the C standard guarantees. This is because the C standard permits much more exotic architectures than FreeBSD actually runs on. > In other words, the (char *)0 part of the pre-commit text was correct, > while after-commit use of NULL only works on machines where pointers > have the same representation as ints or longs. I believe this encompasses all architectures FreeBSD supports — even ignoring our sys/_null.h definition of NULL as (void *)0 or nullptr. Best, Conrad ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r336835 - head/lib/libc/gen
On Sat, Jul 28, 2018 at 07:08:00PM +, Conrad Meyer wrote: > For unclear reasons, POSIX' definition of these routines spells NULL as > "(char *)0." This is needlessly unclear. One guess might be that POSIX > targets more exotic computer architectures than FreeBSD does. Fortunately, > there is no such problem on any reasonable platform for FreeBSD to support. > Spell NULL as NULL. The reasons are quite clear. Practically NULL has to be defined as '0' or '0L' at best, for C and esp. C++ rules of the pointers automatic casts to work. This means that NULL cannot be used in vararg lists where the pointer is expected. In other words, the (char *)0 part of the pre-commit text was correct, while after-commit use of NULL only works on machines where pointers have the same representation as ints or longs. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r336835 - head/lib/libc/gen
Author: cem Date: Sat Jul 28 19:08:00 2018 New Revision: 336835 URL: https://svnweb.freebsd.org/changeset/base/336835 Log: Clean up execl*(3) manual page prototype formatting Rendering of execle was missing a comma between the NULL argument and envp. For unclear reasons, POSIX' definition of these routines comments out the mandatory trailing NULL argument. That seems unnecessary and probably (reasonably) confuses mdoc. For unclear reasons, POSIX' definition of these routines spells NULL as "(char *)0." This is needlessly unclear. One guess might be that POSIX targets more exotic computer architectures than FreeBSD does. Fortunately, there is no such problem on any reasonable platform for FreeBSD to support. Spell NULL as NULL. The comma was probably removed in r117204 while the comment and creative spelling of NULL were added in r116537 (both 15 years ago). Modified: head/lib/libc/gen/exec.3 Modified: head/lib/libc/gen/exec.3 == --- head/lib/libc/gen/exec.3Sat Jul 28 17:21:34 2018(r336834) +++ head/lib/libc/gen/exec.3Sat Jul 28 19:08:00 2018(r336835) @@ -28,7 +28,7 @@ .\" @(#)exec.3 8.3 (Berkeley) 1/24/94 .\" $FreeBSD$ .\" -.Dd January 5, 2016 +.Dd July 28, 2018 .Dt EXEC 3 .Os .Sh NAME @@ -46,16 +46,11 @@ .In unistd.h .Vt extern char **environ ; .Ft int -.Fn execl "const char *path" "const char *arg" ... /* "(char *)0" */ +.Fn execl "const char *path" "const char *arg" ... NULL .Ft int -.Fn execlp "const char *file" "const char *arg" ... /* "(char *)0" */ +.Fn execlp "const char *file" "const char *arg" ... NULL .Ft int -.Fo execle -.Fa "const char *path" "const char *arg" ... -.Fa /* -.Bk -words -.Fa "(char *)0" "char *const envp[]" */ -.Ek +.Fn execle "const char *path" "const char *arg" ... NULL "char *const envp[]" .Fc .Ft int .Fn exect "const char *path" "char *const argv[]" "char *const envp[]" ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
