From owner-freebsd-standards@FreeBSD.ORG Sun May 6 21:11:16 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8F4216A400 for ; Sun, 6 May 2007 21:11:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id B15FD13C483 for ; Sun, 6 May 2007 21:11:16 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.8/8.13.1) with ESMTP id l46Kf2Ap031482; Sun, 6 May 2007 16:41:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.8/8.13.1/Submit) id l46Kf2v8031481; Sun, 6 May 2007 16:41:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 6 May 2007 16:41:02 -0400 From: David Schultz To: Maciej Sobczak Message-ID: <20070506204102.GA31204@VARK.MIT.EDU> Mail-Followup-To: Maciej Sobczak , freebsd-standards@FreeBSD.ORG References: <463C63F1.6050204@msobczak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <463C63F1.6050204@msobczak.com> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Conventions for system headers X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 21:11:17 -0000 On Sat, May 05, 2007, Maciej Sobczak wrote: > Hi (this is my first post to this list), > > The C99 standard defines the following requirement (7.1.2/4): > > "Standard headers may be included in any order [...]" > [...] [...] > I would like to propose a campaign of bringing all FreeBSD system > headers in line with the guarantee that C99 provides for its standard > headers, for the benefit and convenience of both developers and port > maintainers. Which headers did you have in mind? This sounds like a laudable goal, but I'd try to limit it to headers where the requisite changes won't be too obscene. For example, a lot of the networking headers have sensible and standard dependencies. (POSIX says that they may include certain headers that they depend on, but we don't, often resulting in a compile-time error; maybe that should be changed.) Generally try to avoid namespace pollution unless there's a good rationale for it. For instance, if you need , we have a that provides the same definitions, but with internal names that won't conflict with application names. From owner-freebsd-standards@FreeBSD.ORG Mon May 7 06:54:51 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E897D16A400 for ; Mon, 7 May 2007 06:54:50 +0000 (UTC) (envelope-from prog@msobczak.com) Received: from mail1.fluidhosting.com (mx13.fluidhosting.com [204.14.89.3]) by mx1.freebsd.org (Postfix) with SMTP id A111013C469 for ; Mon, 7 May 2007 06:54:50 +0000 (UTC) (envelope-from prog@msobczak.com) Received: (qmail 19967 invoked by uid 399); 7 May 2007 06:54:47 -0000 Received: from localhost (HELO ?128.141.45.244?) (maciej@msobczak.com@127.0.0.1) by localhost with SMTP; 7 May 2007 06:54:47 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <463ECD36.8020701@msobczak.com> Date: Mon, 07 May 2007 08:54:46 +0200 From: Maciej Sobczak User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: freebsd-standards@FreeBSD.ORG References: <463C63F1.6050204@msobczak.com> <20070506204102.GA31204@VARK.MIT.EDU> In-Reply-To: <20070506204102.GA31204@VARK.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Conventions for system headers X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2007 06:54:51 -0000 David Schultz wrote: >> I would like to propose a campaign of bringing all FreeBSD system >> headers in line with the guarantee that C99 provides for its standard >> headers, for the benefit and convenience of both developers and port >> maintainers. > > Which headers did you have in mind? Everything that we consider "system" headers, but was a motivating example that has led me to investigate the whole issue. In general, I would like to see consistent conventions applied to all headers from /usr/include. Additional note: it looks to me that IEEE Std 1003.1 says that is enough for its functions to work, which is also consistent with FreeBSD's own man pages, for example: http://www.freebsd.org/cgi/man.cgi?query=if_nametoindex But in reality is not complete. > This sounds like a laudable > goal, but I'd try to limit it to headers where the requisite > changes won't be too obscene. For example, a lot of the networking > headers have sensible and standard dependencies. (POSIX says that > they may include certain headers that they depend on, but we > don't, often resulting in a compile-time error; maybe that should > be changed.) Exactly. > Generally try to avoid namespace pollution Interestingly, namespace pollution cannot get worse by solving this problem - it can even be potentially reduced. Consider (again, is a good example, but let's keep the discussion general) that a user needs to #include header X.h. If it's not complete, then he has to also #include some additional header before: #include /* required by X.h */ #include If the user omits the first #include, his code will not compile. Now it is clear that in his program the user gets in the global namespace everything from both X.h and Y.h, even though probably only part of Y.h is needed for X.h to work. A simple fix, just to keep the convention that allows arbitrary order, is to #include Y.h from X.h. This way X.h becomes complete - but the namespace pollution does not increase; in fact, the sequence of tokens that the compiler sees is exactly the same. It is just more convenient for the user and consistent with the standards. More complete solution would be of course to refactor common definitions from Y.h and #include them internally from both X.h and Y.h, so that X.h is complete with respect to its own definitions and the additional stuff from Y.h is not necessarily pulled if not needed. This solution would require creating more headers in the system, which is probably more intrusive than it needs to be. I would like to propose to fix the problem the simple way (for the moment) - by just forcibly #include'ing the required headers from their dependants. It will not lead to proliferation of new headers and the namespace pollution will remain the same as it is now. Regards, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ From owner-freebsd-standards@FreeBSD.ORG Mon May 7 11:08:48 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.org Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C81716A413 for ; Mon, 7 May 2007 11:08:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 57A7D13C455 for ; Mon, 7 May 2007 11:08:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l47B8mcs078806 for ; Mon, 7 May 2007 11:08:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l47B8krv078802 for freebsd-standards@FreeBSD.org; Mon, 7 May 2007 11:08:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 May 2007 11:08:46 GMT Message-Id: <200705071108.l47B8krv078802@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2007 11:08:48 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards /bin/sh: null char in quoted string o kern/46239 standards posix semaphore implementation errors o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 5 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec s kern/28260 standards UIO_MAXIOV needs to be made public s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [feature request] add a system call: fd o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards _gettemp uses a far smaller set of filenames than docu o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/85080 standards output of long double subnormals (with printf) is wron o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/104841 standards [libm] [patch] C99 long double square root. o stand/107561 standards [patch] Missing SUS function tcgetsid() o stand/112180 standards tgamma on negative integers returns Inf instead of NaN 37 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon May 7 11:49:24 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.org Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66B3A16A400 for ; Mon, 7 May 2007 11:49:24 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.freebsd.org (Postfix) with ESMTP id E640F13C447 for ; Mon, 7 May 2007 11:49:23 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 970B25A7C2C; Mon, 7 May 2007 21:49:22 +1000 (EST) Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id E39548C0F; Mon, 7 May 2007 21:49:20 +1000 (EST) Date: Mon, 7 May 2007 21:49:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Maciej Sobczak In-Reply-To: <463ECD36.8020701@msobczak.com> Message-ID: <20070507200241.V48720@besplex.bde.org> References: <463C63F1.6050204@msobczak.com> <20070506204102.GA31204@VARK.MIT.EDU> <463ECD36.8020701@msobczak.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@FreeBSD.org Subject: Re: Conventions for system headers X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2007 11:49:24 -0000 On Mon, 7 May 2007, Maciej Sobczak wrote: > David Schultz wrote: > >>> I would like to propose a campaign of bringing all FreeBSD system headers >>> in line with the guarantee that C99 provides for its standard headers, for >>> the benefit and convenience of both developers and port maintainers. >> >> Which headers did you have in mind? > > Everything that we consider "system" headers, but was a motivating > example that has led me to investigate the whole issue. > In general, I would like to see consistent conventions applied to all headers > from /usr/include. > > Additional note: it looks to me that IEEE Std 1003.1 says that is > enough for its functions to work, which is also consistent with FreeBSD's own > man pages, for example: > > http://www.freebsd.org/cgi/man.cgi?query=if_nametoindex That is a bug in if_indextoname.3. I fixed it in rev.1.2, but the fix got clobbered in rev.1.8 by overwriting the file with a foreign version. Rev.1.2 was the result of run a script to check for consistency of includes in man pages. Not fixing rev.1.8 is partly the result of not running (or at least using the output) the script for > 5 years. > But in reality is not complete. Network headers generally have intricate, poorly documented, but very "BSD-standard" prerequisites (see Stevens for how BSD-standard they are). I have another #include-checking script which I haven't run for > 7 years that checks for regressions in historical prerequisites in netorking and other very standard headers. It takes about 1000 lines to list the historical bogus prerequisites, and stopped running because it doesn't list new bogus prerequisites. >> This sounds like a laudable >> goal, but I'd try to limit it to headers where the requisite >> changes won't be too obscene. For example, a lot of the networking >> headers have sensible and standard dependencies. (POSIX says that >> they may include certain headers that they depend on, but we >> don't, often resulting in a compile-time error; maybe that should >> be changed.) > > Exactly. The "may" bug in POSIX should certainly be changed :-). >> Generally try to avoid namespace pollution > > Interestingly, namespace pollution cannot get worse by solving this problem - > it can even be potentially reduced. Yes, but reducing it is difficult. Everything that is used in multiple headers needs to be declared in a common header, perhaps with underscores to limit its visibility. For , this isn't very difficult -- only struct sockaddr, struct sockaddr_storage, struct timeval and a few standard scalar types need to declared in common headers; the sockaddr structs are fairly simple, and struct timeval and the scalar types are already declared with underscores in common headers. The sockaddr structs are nonstandard, at least in draft POSIX.1-2001, so underscored versions would be needed. contains very little in POSIX.1-2001, so it doesn't need struct sockaddr or have a "may" clause allowing it to be polluted with or anything else. OTOH, FreeBSD's is already polluted with all the symbols in , which is in turn polluted with all the symbols in . Other nested pollution (at least when is included and __BSD_VISIBLE is 1) includes all the symbols in and . The pollution with is just to get the declarations of time_t and struct timeval. This is not permitted by POSIX but has been there since rev.1.1, so fixing it is not just a matter of using the central headers that declare __time_t and struct __timeval. > Consider (again, is a good example, but let's keep the discussion > general) that a user needs to #include header X.h. If it's not complete, then > he has to also #include some additional header before: > > #include /* required by X.h */ > #include > > If the user omits the first #include, his code will not compile. > Now it is clear that in his program the user gets in the global namespace > everything from both X.h and Y.h, even though probably only part of Y.h is > needed for X.h to work. This clarity is the only thing that requiring the application to #include everything does -- it is clear that _all_ the symbols in Y.h are visible, while if Y.h is included in X.h, then the programmer has to read the or remember the documentation to know what is included, and the documentation has to be correct. In practice, the documentation is rarely correct, and never in a form that makes the complete pollution clear (due to nested includes and intricate namespace rules). > A simple fix, just to keep the convention that allows arbitrary order, is to > #include Y.h from X.h. This way X.h becomes complete - but the namespace > pollution does not increase; in fact, the sequence of tokens that the > compiler sees is exactly the same. It is just more convenient for the user > and consistent with the standards. It is a bug for standard to allow this, but even POSIX only allows it for a few cases. > More complete solution would be of course to refactor common definitions from > Y.h and #include them internally from both X.h and Y.h, so that X.h is > complete with respect to its own definitions and the additional stuff from > Y.h is not necessarily pulled if not needed. > This solution would require creating more headers in the system, which is > probably more intrusive than it needs to be. This solution is used in almost all cases that have been fixed so far. It is mainly simpler cases that have been fixed -- most things in C99 (which doesn't permit the nexted includes), things near and some networking headers (sys/socket.h and netinet/in.h...). There is still a lot of undocumented pollution but hopefully no nested includes in the useual case where __BSD_VISIBLE is 1. Pollution generally involves going outide of the namespace reserved for a header, and not ducumenting it involves never mentioning of namespaces in FreeBSD man pages (unlike in standards). > I would like to propose to fix the problem the simple way (for the moment) - > by just forcibly #include'ing the required headers from their dependants. It > will not lead to proliferation of new headers and the namespace pollution > will remain the same as it is now. I think this would result in namespace pollution soon growing much larger, since it removes a limit on pullution for new interfaces. Bruce From owner-freebsd-standards@FreeBSD.ORG Tue May 8 02:59:54 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40D6E16A401 for ; Tue, 8 May 2007 02:59:54 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id E193E13C43E for ; Tue, 8 May 2007 02:59:53 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.1/8.13.1) with ESMTP id l482xn7Y008053; Mon, 7 May 2007 22:59:49 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.1/8.13.1/Submit) id l482xmkR008052; Mon, 7 May 2007 22:59:48 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 7 May 2007 22:59:48 -0400 From: David Schultz To: Bruno Haible Message-ID: <20070508025948.GA7859@VARK.MIT.EDU> Mail-Followup-To: Bruno Haible , freebsd-standards@FreeBSD.ORG References: <200704060335.22770.bruno@clisp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704060335.22770.bruno@clisp.org> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: a bug in printf %a X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 02:59:54 -0000 On Fri, Apr 06, 2007, Bruno Haible wrote: > sprintf (buf, "%.2a", 1.51) > should produce "0x1.83p+0". On FreeBSD it produces "0x1.82p+0", which is > incorrect since [1] says: > "For the a and A conversion specifiers, if FLT_RADIX is a power of 2, the > value shall be correctly rounded to a hexadecimal floating number with > the given precision." Fixed in HEAD From owner-freebsd-standards@FreeBSD.ORG Tue May 8 03:01:36 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AF116A400 for ; Tue, 8 May 2007 03:01:36 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id D8DC713C447 for ; Tue, 8 May 2007 03:01:35 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.1/8.13.1) with ESMTP id l4831Vts008093; Mon, 7 May 2007 23:01:31 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.1/8.13.1/Submit) id l4831Vfn008092; Mon, 7 May 2007 23:01:31 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 7 May 2007 23:01:31 -0400 From: David Schultz To: Bruno Haible Message-ID: <20070508030131.GB7859@VARK.MIT.EDU> Mail-Followup-To: Bruno Haible , freebsd-standards@FreeBSD.ORG References: <200704060338.36210.bruno@clisp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704060338.36210.bruno@clisp.org> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: a bug in printf %f and %a X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 03:01:36 -0000 On Fri, Apr 06, 2007, Bruno Haible wrote: > Seen in FreeBSD 6.1. > > printf "%010f" and printf "%010a", applied to NaN, Inf, or -Inf, pad with > zeroes. Should pad with spaces instead. We do exactly what the standard says, which is nonsensical. This looks like a bug in the standard. From owner-freebsd-standards@FreeBSD.ORG Tue May 8 03:02:23 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E08816A401 for ; Tue, 8 May 2007 03:02:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id E494013C44C for ; Tue, 8 May 2007 03:02:22 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.1/8.13.1) with ESMTP id l4832IwS008104; Mon, 7 May 2007 23:02:18 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.1/8.13.1/Submit) id l4832Iwb008103; Mon, 7 May 2007 23:02:18 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 7 May 2007 23:02:18 -0400 From: David Schultz To: Bruno Haible Message-ID: <20070508030218.GC7859@VARK.MIT.EDU> Mail-Followup-To: Bruno Haible , freebsd-standards@FreeBSD.ORG References: <200704060338.36210.bruno@clisp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704060338.36210.bruno@clisp.org> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: a bug in printf %f and %a X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 03:02:23 -0000 On Fri, Apr 06, 2007, Bruno Haible wrote: > Seen in FreeBSD 6.1. > > printf "%010f" and printf "%010a", applied to NaN, Inf, or -Inf, pad with > zeroes. Should pad with spaces instead. Never mind...as the link you provided points out, they fixed the standard. I'll fix the code as well. From owner-freebsd-standards@FreeBSD.ORG Tue May 8 16:14:46 2007 Return-Path: X-Original-To: freebsd-standards@freebsd.org Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC71E16A402 for ; Tue, 8 May 2007 16:14:46 +0000 (UTC) (envelope-from myardbenoit@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id AE22D13C469 for ; Tue, 8 May 2007 16:14:46 +0000 (UTC) (envelope-from myardbenoit@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1800549wxc for ; Tue, 08 May 2007 09:14:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=KM1EBrPwfMLI6V+J3iVLJp/MXZgvhlXeQgWMjy3Z7Kakb4VrwDYLuThm6a1dPb1/VeCKbUAGhPA7cJ78bWC45Vyi3l+jLfDPAqMEudkt82S23WyBID9keBWe76NJT4LrikCEhIDNnudbq2mZ1tK2woM+aM4EptVqyd9NUHQIbfE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dJqe0CWotHO8B4yLriNe7/d+rAbXlkwADhWwCHhbVqXCXjKQ0UM0dEbLLuIwmq/MLbxufoACtHAyuGveUCRu9akQUes9JbLGvecQAREs8jzuQ3a6Qi6YEHZLJZ61qfR/SvU9IihYv2qSJl2UXWWZ4yCoWCxpZ//RZBrDmLLfb2A= Received: by 10.90.52.2 with SMTP id z2mr6395429agz.1178639367841; Tue, 08 May 2007 08:49:27 -0700 (PDT) Received: by 10.90.30.19 with HTTP; Tue, 8 May 2007 08:49:27 -0700 (PDT) Message-ID: <6fb81fc70705080849x48c6de65yd639ee583b03a7f3@mail.gmail.com> Date: Tue, 8 May 2007 17:49:27 +0200 From: "Benoit Myard" To: freebsd-standards@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: (no subject) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 16:14:47 -0000 -- Benoit Myard From owner-freebsd-standards@FreeBSD.ORG Tue May 8 16:15:27 2007 Return-Path: X-Original-To: freebsd-standards@freebsd.org Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D765816A400 for ; Tue, 8 May 2007 16:15:27 +0000 (UTC) (envelope-from myardbenoit@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by mx1.freebsd.org (Postfix) with ESMTP id 99ED113C447 for ; Tue, 8 May 2007 16:15:27 +0000 (UTC) (envelope-from myardbenoit@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1913351wra for ; Tue, 08 May 2007 09:15:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=t0I0Pp9WsK/ahPU3ua4VjV8Ov1VINo509q+M2RZC09JyPyCSSB51X/TkSMlnV14ghHe4o6hLxK+CrTIS5VJk8KwNsdwm7JLagzmIbyyZpYLwpX/OgYYGLEFkYJ7ljwBgty1MIapXL5ONL8ixXx14+UWmhJfEA+akPivb1xCMLuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=d3Uc57nl9uY6DrEkQ7Nzn0jtAZxXMer8Te67tyaubfe20/F6MGA1ty82t727x4XnKD7UcHiI7zldZmgpiHPMcIKq17ASxltQGx1IcZ18eUp9e2EP/gn3W7ARgJ0Ihf+2omXf12e+xsiXYtSwyCWjyAE3itdv21BzT1VuwLDRiQg= Received: by 10.90.116.6 with SMTP id o6mr3476546agc.1178639429798; Tue, 08 May 2007 08:50:29 -0700 (PDT) Received: by 10.90.30.19 with HTTP; Tue, 8 May 2007 08:50:29 -0700 (PDT) Message-ID: <6fb81fc70705080850r30b6cb72ga736072c0d82cbb4@mail.gmail.com> Date: Tue, 8 May 2007 17:50:29 +0200 From: "Benoit Myard" To: freebsd-standards@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: (no subject) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 16:15:27 -0000 -- Benoit Myard From owner-freebsd-standards@FreeBSD.ORG Thu May 10 19:56:51 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.org Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62BFB16A400 for ; Thu, 10 May 2007 19:56:51 +0000 (UTC) (envelope-from prog@msobczak.com) Received: from mail1.fluidhosting.com (mx13.fluidhosting.com [204.14.89.3]) by mx1.freebsd.org (Postfix) with SMTP id 161CD13C448 for ; Thu, 10 May 2007 19:56:50 +0000 (UTC) (envelope-from prog@msobczak.com) Received: (qmail 18554 invoked by uid 399); 10 May 2007 19:56:47 -0000 Received: from localhost (HELO ?192.168.1.13?) (maciej@msobczak.com@127.0.0.1) by localhost with SMTP; 10 May 2007 19:56:47 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <464378FE.1010503@msobczak.com> Date: Thu, 10 May 2007 21:56:46 +0200 From: Maciej Sobczak User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: freebsd-standards@FreeBSD.org References: <463C63F1.6050204@msobczak.com> <20070506204102.GA31204@VARK.MIT.EDU> <463ECD36.8020701@msobczak.com> <20070507200241.V48720@besplex.bde.org> In-Reply-To: <20070507200241.V48720@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Conventions for system headers X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2007 19:56:51 -0000 Bruce Evans wrote: >> http://www.freebsd.org/cgi/man.cgi?query=if_nametoindex > > That is a bug in if_indextoname.3. What about IEEE Std. 1003.1? Does it have a bug as well? >> But in reality is not complete. > > Network headers generally have intricate, poorly documented, but very > "BSD-standard" prerequisites Still, they seem to be breaking current standards. Is BSD heritage valued more? >>> Generally try to avoid namespace pollution >> >> Interestingly, namespace pollution cannot get worse by solving this >> problem - it can even be potentially reduced. > > Yes, but reducing it is difficult. Sure. That's why I would propose the "easy fix" first. > [...] if Y.h is included in X.h, then the programmer has to read the or > remember the documentation to know what is included, and the documentation > has to be correct. That's right. > In practice, the documentation is rarely correct Indeed. ;-) What about creating a script/tool/whatever that will make such a documentation automagically? Surely, this is a good candidate for automation? >> A simple fix, just to keep the convention that allows arbitrary order, >> is to #include Y.h from X.h. This way X.h becomes complete - but the >> namespace pollution does not increase; in fact, the sequence of tokens >> that the compiler sees is exactly the same. It is just more convenient >> for the user and consistent with the standards. > > It is a bug for standard to allow this Why? Can you give some references? The C++ standard explicitly allows headers to #include other standard headers. I cannot find anything in the C standard that would forbid it. In any case, POSIX requires that is complete. >> I would like to propose to fix the problem the simple way (for the >> moment) - by just forcibly #include'ing the required headers from >> their dependants. It will not lead to proliferation of new headers and >> the namespace pollution will remain the same as it is now. > > I think this would result in namespace pollution soon growing much larger, > since it removes a limit on pullution for new interfaces. I still don't understand this argument about pollution - if the header is incomplete, then the user has to "pollute" his namespace on his own. Anyway. Regards, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ From owner-freebsd-standards@FreeBSD.ORG Fri May 11 21:25:34 2007 Return-Path: X-Original-To: freebsd-standards@FreeBSD.ORG Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AD8F16A400 for ; Fri, 11 May 2007 21:25:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 5146B13C447 for ; Fri, 11 May 2007 21:25:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.1/8.13.1) with ESMTP id l4BLPGK1032916; Fri, 11 May 2007 17:25:16 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.1/8.13.1/Submit) id l4BLPG5t032915; Fri, 11 May 2007 17:25:16 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 11 May 2007 17:25:16 -0400 From: David Schultz To: Maciej Sobczak Message-ID: <20070511212516.GA32555@VARK.MIT.EDU> Mail-Followup-To: Maciej Sobczak , freebsd-standards@FreeBSD.ORG References: <463C63F1.6050204@msobczak.com> <20070506204102.GA31204@VARK.MIT.EDU> <463ECD36.8020701@msobczak.com> <20070507200241.V48720@besplex.bde.org> <464378FE.1010503@msobczak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <464378FE.1010503@msobczak.com> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Conventions for system headers X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 21:25:34 -0000 On Thu, May 10, 2007, Maciej Sobczak wrote: > >>A simple fix, just to keep the convention that allows arbitrary order, > >>is to #include Y.h from X.h. This way X.h becomes complete - but the > >>namespace pollution does not increase; in fact, the sequence of tokens > >>that the compiler sees is exactly the same. It is just more convenient > >>for the user and consistent with the standards. > > > >It is a bug for standard to allow this > > Why? Can you give some references? > The C++ standard explicitly allows headers to #include other standard > headers. I cannot find anything in the C standard that would forbid it. C++ is more permissive about this because C++ has namespaces, which are designed specifically to avoid name conflicts. In C it causes real problems. People write programs that declare a reference to their log file as 'FILE *log' and expect it to work as long as they don't include , or they write their own compatibility shims with the same names as standard interfaces, then expect them to work so long as they don't include the system header that may define routines with identical names. Granted, if, for example, included (NB: it doesn't), that wouldn't be too surprising to programmers or likely to cause conflicts. But it would certainly be bad if included , which included , which included , which declares 'struct iovec'. All of this is allowed by POSIX, but I've worked on some server software for a multiplayer game that has its own 'struct iovec', and it would break if we did things this way. So in general we try to avoid that kind of thing. > In any case, POSIX requires that is complete. > > >>I would like to propose to fix the problem the simple way (for the > >>moment) - by just forcibly #include'ing the required headers from > >>their dependants. It will not lead to proliferation of new headers and > >>the namespace pollution will remain the same as it is now. You don't necessarily need a proliferation of new headers. Many of the simple cases (e.g. basic type definitions) can be handled as in . If there's anything that can't be fixed in under 3 lines of code, you're welcome to bring it up on this list.