Bug#665287: <bits/time.h> advertises unsupported clockid_t types
Package: libc0.1-dev
Version: 2.11.3-2
I found this while investigating #662018.
<bits/time.h> advertises the following clockid_t types, however most of them
are not provided. In fact, in most cases we don't have the facilities necessary
to provide them:
# define CLOCK_REALTIME 0
This one is ok AFAIK.
# define CLOCK_PROCESS_CPUTIME_ID 2
This is not supported even on FreeBSD. On Linux-based systems, Linux 2.6.12 or
later is required. I think this macro should be removed.
# define CLOCK_THREAD_CPUTIME_ID 3
This one is supported on FreeBSD, however note that FreeBSD uses the kernel API
(ktimer_create, etc), unlike GNU/kFreeBSD which currently implements
CLOCK_REALTIME in userland.
We *could* use the ktimer_* facilities for this, but it's awkward because
ktimer_create() expects timer_t to be the kernel definition of this type (a
pointer to struct __timer), whereas on GNU/kFreeBSD timer_t is an int32_t
identifier. So if we really want to use the kernel facility we'd have to either
bump ABI and fix the type disparity mess, or write an ugly kludge to map them
(global hash table).
# define CLOCK_MONOTONIC 4
This is #662018. Probably easy to implement on userland.
# ifdef __USE_BSD
# define CLOCK_VIRTUAL 1
# define CLOCK_PROF 2
# define CLOCK_UPTIME 5 /* FreeBSD-specific. */
# define CLOCK_UPTIME_PRECISE 7 /* FreeBSD-specific. */
# define CLOCK_UPTIME_FAST 8 /* FreeBSD-specific. */
# define CLOCK_REALTIME_PRECISE 9 /* FreeBSD-specific. */
# define CLOCK_REALTIME_FAST 10 /* FreeBSD-specific. */
# define CLOCK_MONOTONIC_PRECISE 11 /* FreeBSD-specific. */
# define CLOCK_MONOTONIC_FAST 12 /* FreeBSD-specific. */
# define CLOCK_SECOND 13 /* FreeBSD-specific. */
# endif
These are accurately defined as FreeBSD-specific. Unavailable on GNU/kFreeBSD
because of aforementioned issue. I don't think they should be defined
unless/until we decide we're going to use ktimer_* API.
Note that advertising unsupported features is very harmful because problems
go undetected and even when they're detected it's hard to figure out what
happened. This really needs to be resolved as quickly as possible. My proposal
is to remove affected macros until we're certain that we will be able to
support them.
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc0.1-dev depends on:
ii kfreebsd-kernel-headers 0.53 kernel of FreeBSD headers for deve
ii libc-dev-bin 2.11.3-2 Embedded GNU C Library: Developmen
ii libc0.1 2.11.3-2 Embedded GNU C Library: Shared lib
Versions of packages libc0.1-dev recommends:
ii gcc [c-compiler] 4:4.4.5-1 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.5-4 The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.5-8 The GNU C compiler
Versions of packages libc0.1-dev suggests:
pn glibc-doc <none> (no description available)
ii manpages-dev 3.27-1 Manual pages about using GNU/Linux
-- no debconf information
Reply to: