Date: Fri, 12 Apr 2013 18:46:28 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Garrett Cooper <yaneurabeya@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>, src-committers@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: svn commit: r249355 - head/lib/libkvm Message-ID: <20130412182135.M1222@besplex.bde.org> In-Reply-To: <6ABB36AE-A7AB-4A06-82B9-5E3F07F18AAC@gmail.com> References: <201304110730.r3B7Uo6d067302@svn.freebsd.org> <20130411175308.Q1435@besplex.bde.org> <5166FD40.6040102@freebsd.org> <6ABB36AE-A7AB-4A06-82B9-5E3F07F18AAC@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Apr 2013, Garrett Cooper wrote: > On Apr 11, 2013, at 11:13 AM, Colin Percival wrote: > >> On 04/11/13 00:59, Bruce Evans wrote: >>>> Log: >>>> Include types.h for C99 uintXX_t types. >>> >>> This adds namespace pollution that was carefully left out. >> >> ... and as a developer, I wish we left out such namespace pollution more often. >> >> I write code on FreeBSD which I then publish with the intention that people will >> be able to use it on any POSIX-compliant system, and I've lost count of the >> number of times I've been hit by "this won't build on OS X or Linux because you >> forgot to #include <stdint.h>". Declaring uint64_t and a few other stdint types in <sys/types.h> does tend to give bugs like that. And the pollution is pointless for the kernel (which was originally the only place that used it), since <sys/systm.h> is now polluted with an include of <sys/stdint.h> -- a change that I disagee with. I also disagree with the existence of so many foo/[_]stdint.h headers. There is a machine/_stdint.h and a sys/_stdint.h, a sys/stdint.h and of course a plain stdint.h. At least sys/_stdint.h shouldn't exist. All it does is avoid repeatung the ifdefs for the stdint pollution in sys/types.h. But it was created long after the much larger pollution in sys/systm.h, so it does nothing for the kernel. For userland, it gives the above problem, but it has been there for so long that it is very hard to untangle. sys/types.h still has a comment saying that it shoudn't do this. I have only fixed bugs in this comment and a few nearby things: @ Index: types.h @ =================================================================== @ RCS file: /home/ncvs/src/sys/sys/types.h,v @ retrieving revision 1.90 @ diff -u -2 -r1.90 types.h @ --- types.h 19 Jun 2004 17:58:32 -0000 1.90 @ +++ types.h 20 Jun 2004 02:03:26 -0000 @ @@ -40,8 +40,7 @@ @ @ #include <sys/cdefs.h> @ +#include <sys/_types.h> @ @ -/* Machine type dependent parameters. */ @ #include <machine/endian.h> @ -#include <sys/_types.h> @ @ #if __BSD_VISIBLE Sort includes and remove wrong comment. machine/endian.h doesn't contain type parameters. sys/_types.h contains typedefs, not parameters. @ @@ -57,5 +56,5 @@ @ @ /* @ - * XXX POSIX sized integrals that should appear only in <sys/stdint.h>. @ + * XXX C99 integer types that should appear only in <sys/stdint.h>. @ */ @ #ifndef _INT8_T_DECLARED These types have nothing to do with POSIX, > Funny this would be mentioned. I've seen the converse a lot with Linux devs because they fail to understand that headers on Linux #include a lot more crud than they need to.. > Devs in general don't read the [POSIX] manpages like they should to figure out what needs to be #include'd in order to get function/constant definitions. Third party devs are usually the worst offenders. That's a bit surprising, since glibc tries much harder than FreeBSD to avoid namespace pollution. It has labyrinth includes, partly to avoid namespace pollution and partly to handle machine dependencies. This makes even simple headers unreadable. E.g., fcntl.h. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130412182135.M1222>