This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

CLOCK_* clockid_t value macros


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]