CLOCK_* clockid_t value macros

[Roland McGrath]

Is there any problem with defining the CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID macros even on the systems that don't support them?
I would like to consolidate the bits/time.h files and this is the only
actual difference among any of the supported configurations.

It seems fine to me to define them.  They are not specified by POSIX.1-2001
(only CLOCK_REALTIME is), but permitted.  The spec just says that clock_*
will return EINVAL if given an invalid clockid_t, and so it will for
CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID on systems with no
HP_TIMING support.

I think it's reasonable that programs should need to cope with EINVAL for
these when the macros are present even on machines that currently have
them.  One might very well have a libc where e.g. rdtsc has been disabled
for hardware that doesn't support it.

Does anyone see a problem with this?