Should __clockid_t be used instead of clockid_t in pthread.h?

Raphael Kubo da Costa rakuco at
Mon Mar 19 17:33:55 UTC 2012

Bruce Evans <brde at> writes:

> On Sun, 18 Mar 2012, Raphael Kubo da Costa wrote:
>> Hi there.
>> I'm trying to build an unstable glib version here, and one of their
>> tests fails to build due to them #defining _POSIX_C_SOURCE to 0 and
>> then #including <pthread.h>, which produces the following error on my
>> 8-STABLE machine:
> This gives undefined behaviour.
>> /usr/include/pthread.h:184: error: expected declaration specifiers or '...' before 'clockid_t'
>> /usr/include/pthread.h:187: error: expected declaration specifiers or '...' before 'clockid_t'
>> /usr/include/pthread.h:203: error: expected declaration specifiers or '...' before 'clockid_t'
>> pthread.h gets its definition of clockid_t from time.h, but time.h only
>> creates the typedef if __POSIX_VISIBLE is >= 199309. Using __clockid_t
>> instead of clockid_t in the function prototypes works fine.
>> Should the prototypes be changed?
> time.h is a standard C header, so not defining clockid_t in it when POSIX
> extensions are disabled is correct.
> pthread.h is a not-so-old POSIX header, so it can assume that
> __POSIX_VISIBLE is >= 199309.  Including it when POSIX is not visible,
> or when only an older version of POSIX is visible, is just nonsense
> and can have any result, like the one here.  While using __clockid_t
> in in might make it sort of work, it would remain quite broken.  POSIX
> requires that pthread.h shall make all the namespace pollution in
> time.h (and some other headers) visible.  This is a bug in POSIX.  It
> actually requires that pthread.h shall make all the [POSIX] symbols
> in time.h visible.  pthread.h just includes time.h to get all of these
> symbols, and becomes broken if ones like clockid_t are not declared.
> If pthread.h is actually used, then programs using it will actually
> need some of the symbols like clockid_t from time.h and break when
> they don't explicitly include time.h.

Thank you for the detailed explanation. I've filed a bug in glib's
Bugzilla [1] with a proposed fix that should work on both FreeBSD and


More information about the freebsd-standards mailing list