[PATCH] Fix "/*" within comment warning

Eric Blake eblake@redhat.com
Tue Mar 22 21:08:00 GMT 2016

On 03/22/2016 02:32 PM, Yaakov Selkowitz wrote:

>>>> -/* These types are required by netinet/*.h on Cygwin */
>>>> -#if __BSD_VISIBLE || defined(__CYGWIN__)
>>>> +#if __MISC_VISIBLE
>>>>   #ifndef _BSDTYPES_DEFINED
>>>>   /* also defined in mingw/gmon.h and in w32api/winsock[2].h */
>>>>   #ifndef __u_char_defined
>>> That only works if the parts of our netinet/*.h which use these are
>>> similarly guarded, or their struct members converted to the u_intN_t
>>> types
>>> (as in netinet/ip6.h).'
>> Again, the same headers in Linux use the same types, and these
>> headers do NOT use similar guards.  They just include sys/types.h
>> and expect these types to exist.  If that's good enough for glibc...
> Not sure I understand; `grep -r __USE_ /usr/include/netinet/' shows lots
> of __USE_MISC and even a __USE_GNU ...

POSIX reserves the _entire_ *_t namespace to the implementation, so it
is NOT considered namespace pollution to blindly always expose u_int8_t
and friends from <sys/types.h>, without needing to guard those names
behind certain feature macros.  Note, however, that u_char does NOT fall
into the same boat, and that you must not pollute u_char into the arena
without appropriate guards.  And it is a different question altogether
on whether it is nice to blindly expose non-standard but reserved names
that POSIX saved for us, or whether it is nicer to still require apps to
request those non-standard names with a feature macro.

Also, even though POSIX reserves u_int8_t and friends for our use as
extensions, I still think it would be nicer to directly use the standard
uint8_t instead.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20160322/a5073610/attachment.sig>

More information about the Newlib mailing list