svn commit: r337535 - head/sbin/init

[Warner Losh]

On Thu, Aug 9, 2018 at 3:41 PM, Benjamin Kaduk <bjkfbsd at gmail.com> wrote:

> On Thu, Aug 9, 2018 at 11:03 AM, Conrad Meyer <cem at freebsd.org> wrote:
>
>> On Thu, Aug 9, 2018 at 5:52 AM, Benjamin Kaduk <bjkfbsd at gmail.com> wrote:
>> > On Thu, Aug 9, 2018 at 7:17 AM, Edward Tomasz Napierala <
>> trasz at 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.)
>

The conventional wisdom is code as close to the standard(s) as we can, but
not to the point of insanity. If there's a good reason to deviate, that's
OK so long as it's intentional and the deviation makes sense. For example,
we calloc a bunch of stuff, but that's not a strictly standards conforming
way to initialize pointers to be NULL. While c->ptr = 0 is always standards
conforming, memset(&c->ptr, 0, sizeof(c->ptr)); isn't. Yet we do this
everywhere because we know we'll never run on an architecture where the
bitwise representation of a NULL pointer isn't all 0's. There's dozens of
other similar examples.

Warner