From owner-freebsd-arch@FreeBSD.ORG Sat May 19 22:15:38 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C26BB106566C; Sat, 19 May 2012 22:15:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3858FC0A; Sat, 19 May 2012 22:15:37 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4JMFMw9018504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 May 2012 08:15:24 +1000 Date: Sun, 20 May 2012 08:15:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh In-Reply-To: Message-ID: <20120520072600.R2693@besplex.bde.org> References: <15087.1337452249@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , Poul-Henning Kamp , Robert Millan , freebsd-arch@FreeBSD.org Subject: Re: headers that use "struct bintime" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 22:15:38 -0000 On Sat, 19 May 2012, Warner Losh wrote: > On May 19, 2012, at 12:30 PM, Poul-Henning Kamp wrote: > >> In message <20120520004236.D1313@besplex.bde.org>, Bruce Evans writes: >>> On Sat, 19 May 2012, Poul-Henning Kamp wrote: >> >>>>>> Or maybe "struct bintime" be defined unconditionally? >>>> >>>> I think this is the best/right way to go. >>> >>> Not permitted. >> >>> sys/time.h is still massively polluted in other ways: >>> [...] >>> Not permitted in POSIX.1, [...] >> >> I think at this time, we can either religiously stick to POSIX >> and become irellevant with it, or we can develop our APIs to >> become useful and desirable, and have a chance to survive. > > Doesn't __BSD_VISIBLE do just that? Not when it is not even used. >> Strictly 1980-compatible APIs will not gain FreeBSD 10+ any >> new users. The POSIX.1-1990 support may be unimportant, but is the easiest part of visibility limiting, since POSIX.1-1990 is a subset of everything (except pure STDC (C90) which is even smaller). __BSD_VISIBLE ifdefs support it automatically for all FreeBSD extensions that are not in any version of POSIX. It's the ifdefs for later POSIX versions that are more complicated, or would be if they all existed. now has - only 195 lines matching _VISIBLE - 33 of these are in cdefs.h just to define all the visibility macros - 117 of the remaining the others match __BSD_VISIBLE - only 45 others (mainly with __POSIX_VISIBLE and __XSI_VISIBLE - a whole 7 of these 45 match 1993 and a whole 14 of the 45 match 2001. POSIX grew from ~356 pages in 1990 to 3600 pages in 2001 (d7.pdf draft; it now covers utilities). The new and changed interfaces can't be expressed by 7+14 ifdefs. After 2001, it only grew to 3790 pages in a 2007 draft. FreeBSD doesn't have any ifdefs to express the 2001-2007 changes (I think there were no POSIX.1 standards releases in this period), but it have a whole 5 new ifdefs for the 2008 version. Functions like futimes() are newer still (not in any POSIX.1 released standard) but are under a __BSD_VISIBLE ifdef. Bruce