From owner-freebsd-standards Fri Oct 11 12:51: 9 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C678437B401; Fri, 11 Oct 2002 12:51:08 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8043A43E8A; Fri, 11 Oct 2002 12:51:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0005.cvx21-bradley.dialup.earthlink.net ([209.179.192.5] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1805oP-0005ox-00; Fri, 11 Oct 2002 12:51:05 -0700 Message-ID: <3DA72B5D.97C8E6A8@mindspring.com> Date: Fri, 11 Oct 2002 12:49:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Craig Rodrigues , freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Problem detecting POSIX symbolic constants References: <20021011184643.U12170-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > _POSIX_REALTIME_SIGNALS is only valid in versions of POSIX that support > it. Applications must also conditionalize on _POSIX_VERSION if they > want to check for features that are not in all versions. Yeah; I mentioned that I was afraid of this... > Runtime configuration only lets us go forward in time. An application > might use POSIX realtime features if they are available and magically > start working better (without recompiling anything in the application) > when the OS and/or library implementors get around to implementing the > features. Don't get me wrong; I understand why the feature is defined; I just don't think that any sane programmer is going to write two sets of runtime variant code, when they can write one set of compile time variant, but runtime invariant, code. The POSIX committee would do us all a favor if, instead of doing things like this, they concentrated on standardizing shared memory, distributed file locking, and the ability to free up ranges of blocks in the middle of files (as examples). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message