svn commit: r314780 - head/lib/libpam/modules/pam_exec

[Bruce Evans]

On Sun, 12 Mar 2017, Ngie Cooper wrote:

>> On Mar 12, 2017, at 11:04, Ian Lepore <ian at freebsd.org> wrote:
>
> ...
>
>> A quirk of C that's often forgotten is that a function-like macro is
>> only expanded as a macro if the token following the macro name is an
>> open paren.  So nitems() is a macro invokation and nitems = 0; is just
>> a variable.

Perhaps it was a quirk in some pre-C90 compilers, but it is now intentional.

>> I'm not arguing against the replacement of variables named nitems, I
>> actually think that should have been done as part of importing the
>> function-like definition of nitems from netbsd.

I am arguing against it.  Changing the it in the application would be
punishing the application for the system stealing the application's
namespace with undocumented pollution.

> Minor correction (as Pedro noted later):
> - NetBSD uses __arraycount.
> - OpenBSD uses nitems.
> FreeBSD has standardized on nitems, probably because it came about in 8.x, whereas __arraycount came about later.

Good for NetBSD.  __arraycount is not pollution and is clearly unusable in
applications, at least when undocumented, since its name is reserved for
the implementation.

BTW, I lost the mail about churning HZ.  Neither HZ or Hz is correct.  HZ
is only a bad name for the compile time default for the frequency of
"clock ticks".  The runtime frequency of "clock ticks" has the bad name
"hz".  The comment is trying to describe the latter.  That is wrong too
(see below).  These names are bad because the name of a variable holding
a freqency, or even the value of the variable, are very different from
the units of the variable.

"clock ticks" at the frequency of the misnamed variable "hz" are partly
virtual now. On modern x86, there is no periodic clock, but one running
at frequency hz is faked.  The comment is trying to refer to this clock.
But this is not the clock controlling the accuracy of the so-called
"HZ" timestamp precision (TSP_HZ_.  When hz is too large, the virtual
clock ticks at frequency hz are scaled down by a factor of tc_tick that
is larger than 1.  This gives an accuracy of about 1/(hz/tc_tick).

/sys/kern doesn't have many conflations of units with values under the
spelling HZ (I think it has lots under the spelling hz; these are hard
to avoid since the variable hz sometimes gives the correct frequency):
- kern_poll.c says HZ=1000 in a comment (it means something like hz=1000)
- sched_ule.c has a conversion macro named SCHED_TICK_HZ (it means from
   ticks in local units to ticks at frequency hz)
- subr_param.c copies the bad example set by the config parameter HZ for
   HZ_VM
- vfs_subr.c has 2 instances of HZ which should be (hz/tc_tick), and
   2 instances of TSP_HZ.

The sysctl for tc_tick has an incomplete description.  It says that
tc_tick is the "Approximate number of hardclock ticks in a
millisecond".  This is a bit verbose, but it avoids conflations with
Hz and complications with the hz variable and units errors for "milli".
But the stated approximation is impossible when hz is much smaller
than 1000.  Then tc_tick is 1.

The sysctl is read-only, so users can't modify the scale factor to get
more accuracy from TSP_HZ, etc.  The implementation depends on hz/tc_tick
being not much larger than 1000 (to work on slow or high latency systems)
and tc_tick is chosen to give this.  So description comment remains correct
if it was correct originally.  It is still simpler to describe this as
a scale factor.  It is not useful for users to know that this variable
holds the stated value (except when it doesn't).  It is useful for them
to know that it scales the accuracy of hardclock ticks in some cases.

Bruce