svn commit: r298247 - head/sbin/fdisk_pc98

[Pedro Giffuni]

On 04/20/16 10:15, Bruce Evans wrote:
> On Wed, 20 Apr 2016, Conrad Meyer wrote:
>
>> On Wed, Apr 20, 2016 at 7:33 AM, Pedro Giffuni <pfg at freebsd.org> wrote:
>>> One of the things I dislike is that most of the macros are in
>>> lowercase. Lowercase would make sense if these were inline functions
>>> but inline functions have disadvantages for these use cases.
>>> OTOH, if they were uppercase, they would not be very easy on the eyes,
>>> which is the current advantage.
>
> Lower case is correct if nitems is a safe macro.  I think it is safe,
> because its parameter must be an array and an expression with side
> effects can't be an array.
>

Ahh .. so I guess it's not that bad then :-/.

>> You bring up a good point.  Obviously nitems() can't be an inline
>> function, but roundup2() and friends could.  Is there any reason not
>> to change them over to inline functions?
>
> 1. Namespace pollution.  Adding nitems() to sys/param.h already broke
>    anything using that name.
>

Yes, and there's nothing to do now.

> 2. roundup2() and friends can't be inline functions without unportable
>    complications to make them type-generic.  No one ever did this for
>    the more important imin() family of inline functions.  4.4BSD removed
>    the MAX() and MIN() macros in the kernel to enforce use of the imin()
>    family, but this gave type errors and was routed around by restoring
>    the macros, first in scattered places and then back in sys/param.h.
>

I see, the imin() stuff is in sys/libkern.h. Looks like a nice use case
for coccinelle.

Pedro.