Ben Harris <bjh21@netbsd.org> writes:
> This seems like a bad idea, given that sysconf(_SC_CLK_TCK) doesn't return
> the same old constant, unless you provide a back-compatibility version of
> times().

Well, actually on most ports in most circumstances it does. An x86
user, for example, would only notice if he played with HZ.

This will impact mostly people who are running on ALPHA and don't
rebuild or who play with HZ. It also won't really break anything -- at
worst, you'll get incorrect values out.

The reason I'm not particularly concerned is given how utterly broken
use of times() is in the first place. The call should be extirpated
from our sources. If you look at how it is defined, for example, its
error return overlaps with its legitimate return range, to name only
one problem with it.

So, to repeat, this is not like breaking a call with wide legitimate
use...

> For example, our /bin/ksh has a "times" builtin that uses CLK_TCK to scale
> the results of times().

I'd strongly suggest we fix that to use getrusage.

It is one of only two apps that actually use times in our sources,
actually.

> 1: Versioning times() in the same way as has been done with other calls
>    (e.g. glob), so that existing binaries get the old (CLK_TCK==100)
>    version, and new ones get the new version.

If you want to do that, sure. Just set CLK_TCK to 100 for purposes of
the old call. However, do you REALLY want to do this for the sake of a
tiny number of apps ?

> 2: Changing _SC_CLK_TCK so that the old version still returns a constant
>    100, while the new one returns something variable.  This will save
>    versioning sysconf.

I don't think that is necessary -- old sources assume CLK_TCK, as was
defined in the old POSIX, and not _SC_CLK_TCK. Anything properly using
_SC_CLK_TCK is new.

> I might have some spare time to do this myself in the near future, if it's
> agreed to be a good idea.

I'm very unsure it is. We are talking about something that really,
really impacts almost nothing. I suspect that no one would actually
notice except for our paranoia about it.

More potent I suspect will be my intent to change clock() and
CLOCKS_PER_SEC to conform (CLOCKS_PER_SEC is required to be 1E6).  We
*might* want to version that, although so far as I can tell literally
no sources in our tree are impacted. (All our actual uses are in
regression tests. The call appears in our sources, but always ifdef'ed
so we don't use it.)

-- 
Perry E. Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you..."