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] |
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] |