svn commit: r298247 - head/sbin/fdisk_pc98

Bruce Evans brde at optusnet.com.au
Wed Apr 20 15:15:29 UTC 2016


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.

> 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.

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.

    2-arg type-generic functions are especially difficult since they have
    N^2 combinations where N is approximately the number of types in
    inttypes.h.  There are 8 basic types just for 8/16/32/64 bits signed
    and unsigned.  For compaibility, the result type must be the same as
    what the macro gives.

Bruce


More information about the svn-src-all mailing list