Re: standards/48339: _POSIX_C_SOURCE and <dev/usb/usb.h> don't mix

[Klaus Klein <kleink%kleink.org@localhost>]

The following reply was made to PR kern/48339; it has been noted by GNATS.

From: Klaus Klein <kleink%kleink.org@localhost>
To: David Holland <dholland-bugs%netbsd.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: standards/48339: _POSIX_C_SOURCE and <dev/usb/usb.h> don't mix
Date: Sat, 2 Nov 2013 23:57:57 +0100

 Am 02.11.2013 um 18:33 schrieb David Holland 
<dholland-bugs%netbsd.org@localhost>:
 
 > On Thu, Oct 24, 2013 at 07:40:00PM +0000, rhialto%falu.nl@localhost wrote:
 >>     The following small program fails to compile:
 >>=20
 >> $ cat j.c
 >> #define _POSIX_C_SOURCE
 >> #include <dev/usb/usb.h>
 >>=20
 >> int main(int argc, char *argv[])
 >> {
 >>    return 0;
 >> }
 >=20
 > "don't do that"
 >=20
 > POSIX doesn't define USB drivers, so in principle once you do set
 > _POSIX_C_SOURCE it should refuse to even find usb.h.
 
 Actually the application might be what=92s called a conforming POSIX =
 application using extensions; while the feature test macro restricts =
 what=92s made visible by the headers defined in the standard it doesn=92t =
 preclude the use of non-POSIX headers in such an application (that=92d =
 be a requirement for a strictly conforming application).
 
 That said, I think having this work could be worthwhile to have, so...
 
 >>> Fix:
 >>     Probably <dev/usb/usb.h> should use more (standard or at least
 >>     certain to be defined) types, such as uint{8,16,32}_t or plain
 >>     unsigned char, unsigned int and unsigned long.
 >=20
 > probably won't hurt anything.
 
 ...I=92ll have a look. (Dito kern/48340.)
 
 
 - Klaus