Should __clockid_t be used instead of clockid_t in pthread.h?
brde at optusnet.com.au
Mon Mar 19 09:02:29 UTC 2012
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.
More information about the freebsd-standards