Then maybe don’t keep bringing it up? Especially when it’s totally irrelevant, like here. FreeBSD has certain assumptions of supported platforms beyond the guarantees of standard C that have nothing whatsoever to do with the boogeyman of a patched compiler.
On Thu, Aug 9, 2018 at 2:42 PM Benjamin Kaduk <bjkf...@gmail.com> wrote: > On Thu, Aug 9, 2018 at 11:03 AM, Conrad Meyer <c...@freebsd.org> wrote: > >> On Thu, Aug 9, 2018 at 5:52 AM, Benjamin Kaduk <bjkf...@gmail.com> wrote: >> > On Thu, Aug 9, 2018 at 7:17 AM, Edward Tomasz Napierala < >> tr...@freebsd.org> >> > wrote: >> >> Use NULLs instead of casted zeroes, for consistency. >> > >> > It's probably helpful to note explicitly that these are not in >> arguments to >> > varargs functions, >> >> I don't think it's helpful. >> >> > in which case the explicit cast is needed in order to produce a program >> that >> > will have >> > correct behavior on all compliant compilers/systems. >> >> Here "compliant" means "minimally compliant to the C standard." Use >> of NULL in varargs is functionally correct on all FreeBSD systems. >> >> > (We do define NULL to >> > be a zero-with-cast, >> > but programs >> >> (Ones that care about portability to weird systems.) I don't think >> BSD's 500 line init — hyper local to FreeBSD — is a strong candidate >> for portability. >> >> > should not assume that NULL will be of pointer type -- "An >> > integer constant >> > expression with the value 0, or such an expression cast to type void *, >> is >> > called a null pointer constant".) >> >> Right. The problem only arises when both conditions are met: >> >> 1. The system's varargs representation is smaller than the pointer >> representation, and >> 2. The runtime headers do not defined NULL as a pointer-typed value. >> (3. The function being invoked is actually varargs?) >> >> Neither is true on FreeBSD and v7-style init is not a useful place to >> call for portability. >> > > I don't really feel a need to continue the discussion that was already > started in response > to r336835 (in addition to the current thread), so I'll limit myself to > asking whether we > want to be writing standard C or a FreeBSD-specific dialect of C. My > understanding was > that we had some experience with the latter (e.g., heavy patching of the > compiler) and > it ended up with us in a bad place, which would tend to support writing > standard C or > as close to it as we can. (Yes, I know that we have non-standard printf > specifiers and the like.) > > -Ben > _______________________________________________ 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"