Why is TUNABLE_INT discouraged?

[Ed Maste]

On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote:

> 2010/8/8 Dag-Erling Sm??rgrav <des at des.no>:
> > Garrett Cooper <gcooper at FreeBSD.org> writes:
> >> Dag-Erling Sm??rgrav <des at des.no> writes:
> >> > Perhaps. ??I don't remember all the details; I can't find a discussion in
> >> > the list archives (other than me announcing the change in response to a
> >> > bug report), but there must have been one, either on IRC or in Karlsruhe.
> >> > In any case, I never removed TUNABLE_INT(), so...
> >> It does matter for integers on 64-bit vs 32-bit architectures though,
> >> right
> >
> > Not sure what you mean. ??The original issue was that someone had used
> > TUNABLE_INT() for something that was actually a memory address. ??I
> > changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a boolean
> > value or something like maxprocs, an int is fine - but so is a long.
> 
> Semantically valid but using TUNABLE_INT to hold pointers is a
> developer bug, not the fault of the API, and there's nothing wrong
> with "int" as a data type in this context.

I agree with Ivan here.  If we can't find an actual reason to
universally prefer long I'd like to remove this comment.

As a counterpoint to the preference for long I can offer a reason to
prefer int: the same variable is often exposed by both a tunable and a
sysctls, and a sysctl using long can have 32-bit compat issues.  (That
is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.)

-Ed