From owner-freebsd-standards Sun Oct 6 18:52:41 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 7FB8637B401 for ; Sun, 6 Oct 2002 18:52:40 -0700 (PDT) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3801843E86 for ; Sun, 6 Oct 2002 18:52:40 -0700 (PDT) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id 687879C0A; Sun, 6 Oct 2002 21:45:20 -0400 (EDT) Date: Sun, 6 Oct 2002 21:45:20 -0400 From: Mike Barcroft To: standards@FreeBSD.org Subject: restrict qualifier task Message-ID: <20021006214520.B97120@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: The FreeBSD Project 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 If someone's looking for an easy task to do, the following functions are missing restrict type-qualifiers: signal.h: sigwait() stdio.h: fgetpos(), fgets(), fopen(), fputs(), fread(), freopen(), fscanf(), fwrite(), scanf(), sscanf(), vscanf(), vsscanf() Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Oct 6 19:36:16 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 7933137B401 for ; Sun, 6 Oct 2002 19:36:14 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9D7943E6A for ; Sun, 6 Oct 2002 19:36:13 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g972asPe007850 for ; Sun, 6 Oct 2002 22:36:54 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g972arCj007849 for freebsd-standards@freebsd.org; Sun, 6 Oct 2002 22:36:53 -0400 (EDT) Date: Sun, 6 Oct 2002 22:36:53 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021006223653.A7728@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021006214520.B97120@espresso.q9media.com>; from mike@FreeBSD.org on Sun, Oct 06, 2002 at 09:45:20PM -0400 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 On Sun, Oct 06, 2002 at 09:45:20PM -0400, Mike Barcroft wrote: > > If someone's looking for an easy task to do, the following functions > are missing restrict type-qualifiers: > > signal.h: > sigwait() > > stdio.h: > fgetpos(), fgets(), fopen(), fputs(), fread(), freopen(), fscanf(), > fwrite(), scanf(), sscanf(), vscanf(), vsscanf() Hi, I might be interested in this. What is required? Is it just a matter of making the prototypes of these functions the same as the ISO C99 standard (for stdio.h) and the latest SUSv3 standard for sigwait? Would this require modifying .h, .c, and man pages? Is there a ISO C99 standard (or draft) that is available online? I don't have the full standard. For the SUSv3 standard (sigwait), what do you specify in the STANDARDS section of the man page? On, http://www.opengroup.org/onlinepubs/007904975/functions/sigwait.html, it lists the standard as IEEE Std 1003.1-2001. ("The restrict keyword is added to the sigwait() prototype for alignment with the ISO/IEC 9899:1999 standard. ") By the way, this isn't quite what you wanted, but here is a spelling fix: --- sys/sys/cdefs.h.orig Sun Oct 6 22:20:44 2002 +++ sys/sys/cdefs.h Sun Oct 6 22:20:53 2002 @@ -139,7 +139,7 @@ #endif /* - * GCC 2.95 provides `__restrict' as an extention to C90 to support the + * GCC 2.95 provides `__restrict' as an extension to C90 to support the * C99-specific `restrict' type qualifier. We happen to use `__restrict' as a * way to define the `restrict' type qualifier without disturbing older software * that is unaware of C99 keywords. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Oct 6 19:54:34 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 AE93237B401 for ; Sun, 6 Oct 2002 19:54:32 -0700 (PDT) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AC2143E65 for ; Sun, 6 Oct 2002 19:54:32 -0700 (PDT) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id EA8D89BC3; Sun, 6 Oct 2002 22:47:11 -0400 (EDT) Date: Sun, 6 Oct 2002 22:47:11 -0400 From: Mike Barcroft To: Craig Rodrigues Cc: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021006224711.C97120@espresso.q9media.com> References: <20021006214520.B97120@espresso.q9media.com> <20021006223653.A7728@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021006223653.A7728@attbi.com>; from rodrigc@attbi.com on Sun, Oct 06, 2002 at 10:36:53PM -0400 Organization: The FreeBSD Project 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 Craig Rodrigues writes: > On Sun, Oct 06, 2002 at 09:45:20PM -0400, Mike Barcroft wrote: > > > > If someone's looking for an easy task to do, the following functions > > are missing restrict type-qualifiers: > > > > signal.h: > > sigwait() > > > > stdio.h: > > fgetpos(), fgets(), fopen(), fputs(), fread(), freopen(), fscanf(), > > fwrite(), scanf(), sscanf(), vscanf(), vsscanf() > > Hi, > > I might be interested in this. What is required? > Is it just a matter of making the > prototypes of these functions the same as the ISO C99 standard (for stdio.h) > and the latest SUSv3 standard for sigwait? > Would this require modifying .h, .c, and man pages? Yes, you need to update the header in include, the libc .c files, and the libc man pages. > Is there a ISO C99 standard (or draft) that is available online? > I don't have the full standard. POSIX/SUSv3 covers C99 functions also. > For the SUSv3 standard (sigwait), what do you specify in the STANDARDS > section of the man page? If you change the STANDARDS section, you should verify that it does indeed conform to the specification and then use `.St -p1003.1-2001'. This isn't really part of the task, but you can do it if you like. Someone will need to go through each function and check conformance at some point anyway. > On, http://www.opengroup.org/onlinepubs/007904975/functions/sigwait.html, > it lists the standard as IEEE Std 1003.1-2001. > > ("The restrict keyword is added to the sigwait() prototype for > alignment with the ISO/IEC 9899:1999 standard. ") > > > > By the way, this isn't quite what you wanted, but here is a spelling fix: [...] Committed, thanks. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 12: 4:34 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 72E2037B401 for ; Mon, 7 Oct 2002 12:04:33 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5D1F43E6E for ; Mon, 7 Oct 2002 12:04:32 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g97J5DPe011093 for ; Mon, 7 Oct 2002 15:05:13 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g97J5DqT011092 for freebsd-standards@freebsd.org; Mon, 7 Oct 2002 15:05:13 -0400 (EDT) Date: Mon, 7 Oct 2002 15:05:13 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021007150513.A11025@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> <20021006223653.A7728@attbi.com> <20021006224711.C97120@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021006224711.C97120@espresso.q9media.com>; from mike@FreeBSD.org on Sun, Oct 06, 2002 at 10:47:11PM -0400 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 On Sun, Oct 06, 2002 at 10:47:11PM -0400, Mike Barcroft wrote: > Craig Rodrigues writes: > > On Sun, Oct 06, 2002 at 09:45:20PM -0400, Mike Barcroft wrote: > > > > > > If someone's looking for an easy task to do, the following functions > > > are missing restrict type-qualifiers: For this task, is it better to use the C99 restrict keyword itself, or use the __restrict macro defined in ? statvfs() uses __restrict in the header file, but documents "restrict" in the man page. pselect() uses __restrict in the header file, but doesn't document "restrict" or "__restrict" in the man page. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 12:10: 5 2002 Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A27FE37B401 for ; Mon, 7 Oct 2002 12:10:03 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E00A043E91 for ; Mon, 7 Oct 2002 12:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g97JA2Co016982 for ; Mon, 7 Oct 2002 12:10:02 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g97JA2kt016981; Mon, 7 Oct 2002 12:10:02 -0700 (PDT) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86B3137B401 for ; Mon, 7 Oct 2002 12:03:32 -0700 (PDT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 430EE43E6E for ; Mon, 7 Oct 2002 12:03:32 -0700 (PDT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.6/8.12.6) with ESMTP id g97J3W7R078252 for ; Mon, 7 Oct 2002 12:03:32 -0700 (PDT) (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.6/8.12.6/Submit) id g97J3WFV078251; Mon, 7 Oct 2002 12:03:32 -0700 (PDT) Message-Id: <200210071903.g97J3WFV078251@www.freebsd.org> Date: Mon, 7 Oct 2002 12:03:32 -0700 (PDT) From: Peter Johnson To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: standards/43780: PATCH: long long functions in stdlib.h should be wrappered with __STRICT_ANSI__ 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 >Number: 43780 >Category: standards >Synopsis: PATCH: long long functions in stdlib.h should be wrappered with __STRICT_ANSI__ >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 07 12:10:02 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Peter Johnson >Release: 4.7-RC >Organization: >Environment: FreeBSD powerplant.home.bilogic.org 4.7-RC FreeBSD 4.7-RC #7: Mon Oct 7 01:01:51 PDT 2002 freebsd@powerplant.home.bilogic.org:/usr/obj/usr/src/sys/WORKSTATION i386 >Description: Compiling code that includes stdlib.h with the GCC options -ansi -pedantic reports the following warnings on two lines of stdlib.h: /usr/include/stdlib.h:110: warning: ANSI C does not support `long long' /usr/include/stdlib.h:114: warning: ANSI C does not support `long long' These lines are the strtoll and strtoull functions. >How-To-Repeat: Compile a short program with gcc -ansi -pedantic that includes stdlib.h: #include int main() { return 0; } >Fix: Add #ifndef __STRICT_ANSI__ wrappers around the offending lines: --- include/stdlib.h.orig Wed Aug 14 19:07:57 2002 +++ include/stdlib.h Mon Oct 7 12:00:48 2002 @@ -106,12 +106,16 @@ void srand __P((unsigned)); double strtod __P((const char *, char **)); long strtol __P((const char *, char **, int)); +#ifndef __STRICT_ANSI__ long long strtoll __P((const char *, char **, int)); +#endif unsigned long strtoul __P((const char *, char **, int)); +#ifndef __STRICT_ANSI__ unsigned long long strtoull __P((const char *, char **, int)); +#endif int system __P((const char *)); int mblen __P((const char *, size_t)); >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 12:34:37 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 31E8337B401 for ; Mon, 7 Oct 2002 12:34:36 -0700 (PDT) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D39543E97 for ; Mon, 7 Oct 2002 12:34:35 -0700 (PDT) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id 7DAAE9BC3; Mon, 7 Oct 2002 15:27:13 -0400 (EDT) Date: Mon, 7 Oct 2002 15:27:13 -0400 From: Mike Barcroft To: Craig Rodrigues Cc: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021007152713.F97120@espresso.q9media.com> References: <20021006214520.B97120@espresso.q9media.com> <20021006223653.A7728@attbi.com> <20021006224711.C97120@espresso.q9media.com> <20021007150513.A11025@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021007150513.A11025@attbi.com>; from rodrigc@attbi.com on Mon, Oct 07, 2002 at 03:05:13PM -0400 Organization: The FreeBSD Project 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 Craig Rodrigues writes: > On Sun, Oct 06, 2002 at 10:47:11PM -0400, Mike Barcroft wrote: > > Craig Rodrigues writes: > > > On Sun, Oct 06, 2002 at 09:45:20PM -0400, Mike Barcroft wrote: > > > > > > > > If someone's looking for an easy task to do, the following functions > > > > are missing restrict type-qualifiers: > > For this task, is it better to use the C99 restrict keyword itself, or use the __restrict > macro defined in ? > > statvfs() uses __restrict in the header file, but documents "restrict" in the man page. This is how it should be done. > pselect() uses __restrict in the header file, but doesn't document "restrict" or "__restrict" in the man page. Can you fix this in your patch? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 17: 9: 3 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 1636337B401 for ; Mon, 7 Oct 2002 17:09:02 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6306C43E65 for ; Mon, 7 Oct 2002 17:09:01 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9800iPe012609 for ; Mon, 7 Oct 2002 20:00:44 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9800iFr012608 for freebsd-standards@freebsd.org; Mon, 7 Oct 2002 20:00:44 -0400 (EDT) Date: Mon, 7 Oct 2002 20:00:43 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021007200043.A12581@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> <20021006223653.A7728@attbi.com> <20021006224711.C97120@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021006224711.C97120@espresso.q9media.com>; from mike@FreeBSD.org on Sun, Oct 06, 2002 at 10:47:11PM -0400 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 Hi, I am working on the patches now for this task. I have a question. In /usr/src/include/signal.h, there is a preprocessor check for _ANSI_SOURCE: 53 __BEGIN_DECLS 54 int raise(int); 55 #ifndef _ANSI_SOURCE 56 int kill(__pid_t, int); 57 int sigaction(int, const struct sigaction *, struct sigaction *); 58 int sigaddset(sigset_t *, int); 59 int sigdelset(sigset_t *, int); 60 int sigemptyset(sigset_t *); 61 int sigfillset(sigset_t *); 62 int sigismember(const sigset_t *, int); 63 int sigpending(sigset_t *); 64 int sigprocmask(int, const sigset_t *, sigset_t *); 65 int sigsuspend(const sigset_t *); 66 int sigwait(const sigset_t *, int *); 67 Can I add the __restrict keyword to sigwait, or do I need to do something special because of the _ANSI_SOURCE preprocessor check? ie. would I have to move the prototype for sigwait() to underneath raise()? -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 17:22:34 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 9CC4137B401 for ; Mon, 7 Oct 2002 17:22:32 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAF6143E42 for ; Mon, 7 Oct 2002 17:22:31 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g980NDPe012724 for ; Mon, 7 Oct 2002 20:23:13 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g980NCP3012723 for freebsd-standards@freebsd.org; Mon, 7 Oct 2002 20:23:12 -0400 (EDT) Date: Mon, 7 Oct 2002 20:23:12 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021007202312.A12702@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> <20021006223653.A7728@attbi.com> <20021006224711.C97120@espresso.q9media.com> <20021007200043.A12581@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021007200043.A12581@attbi.com>; from rodrigc@attbi.com on Mon, Oct 07, 2002 at 08:00:43PM -0400 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 Hi, OK, I had just cvsup'd, and I now realize that this file has changed quite a bit and _ANSI_SOURCE is no longer in signal.h. Sorry for the confusion. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com On Mon, Oct 07, 2002 at 08:00:43PM -0400, Craig Rodrigues wrote: > Hi, > > I am working on the patches now for this task. > I have a question. > > In /usr/src/include/signal.h, there is a preprocessor check > for _ANSI_SOURCE: > > 53 __BEGIN_DECLS > 54 int raise(int); > 55 #ifndef _ANSI_SOURCE > 56 int kill(__pid_t, int); > 57 int sigaction(int, const struct sigaction *, struct sigaction *); > 58 int sigaddset(sigset_t *, int); > 59 int sigdelset(sigset_t *, int); > 60 int sigemptyset(sigset_t *); > 61 int sigfillset(sigset_t *); > 62 int sigismember(const sigset_t *, int); > 63 int sigpending(sigset_t *); > 64 int sigprocmask(int, const sigset_t *, sigset_t *); > 65 int sigsuspend(const sigset_t *); > 66 int sigwait(const sigset_t *, int *); > 67 > > > Can I add the __restrict keyword to sigwait, or do I need to do > something special because of the _ANSI_SOURCE preprocessor check? > ie. would I have to move the prototype for sigwait() to underneath > raise()? > > > -- > Craig Rodrigues > http://www.gis.net/~craigr > rodrigc@attbi.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-standards" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 19:40: 7 2002 Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 999F837B401 for ; Mon, 7 Oct 2002 19:40:06 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 575C643E3B for ; Mon, 7 Oct 2002 19:40:06 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g982e5Co027696 for ; Mon, 7 Oct 2002 19:40:06 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g982e5tM027692; Mon, 7 Oct 2002 19:40:05 -0700 (PDT) Date: Mon, 7 Oct 2002 19:40:05 -0700 (PDT) Message-Id: <200210080240.g982e5tM027692@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org Cc: From: Tim Robbins Subject: Re: standards/43780: PATCH: long long functions in stdlib.h should be wrappered with __STRICT_ANSI__ Reply-To: Tim Robbins 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 The following reply was made to PR standards/43780; it has been noted by GNATS. From: Tim Robbins To: Peter Johnson Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: standards/43780: PATCH: long long functions in stdlib.h should be wrappered with __STRICT_ANSI__ Date: Tue, 8 Oct 2002 12:36:07 +1000 On Mon, Oct 07, 2002 at 12:03:32PM -0700, Peter Johnson wrote: > >Description: > Compiling code that includes stdlib.h with the GCC options -ansi -pedantic > reports the following warnings on two lines of stdlib.h: > /usr/include/stdlib.h:110: warning: ANSI C does not support `long long' > /usr/include/stdlib.h:114: warning: ANSI C does not support `long long' > These lines are the strtoll and strtoull functions. This is fixed in -CURRENT. I'll try to get the change MFC'd for 4.8 (it's too late to do it for 4.7). Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Oct 7 20:20: 8 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 DE98937B401 for ; Mon, 7 Oct 2002 20:19:58 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA52A43E75 for ; Mon, 7 Oct 2002 20:19:57 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g983KcPe013788 for ; Mon, 7 Oct 2002 23:20:39 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g983KcoH013787 for freebsd-standards@freebsd.org; Mon, 7 Oct 2002 23:20:38 -0400 (EDT) Date: Mon, 7 Oct 2002 23:20:38 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021007232038.A13773@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021006214520.B97120@espresso.q9media.com>; from mike@FreeBSD.org on Sun, Oct 06, 2002 at 09:45:20PM -0400 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 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Here is my patch. __restrict was already added to sigwait() in the .c file and man page, but not in the header file. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="restrict-patch.txt" --- ./include/signal.h.orig Mon Oct 7 20:23:24 2002 +++ ./include/signal.h Mon Oct 7 20:24:49 2002 @@ -72,8 +72,7 @@ int sigpending(sigset_t *); int sigprocmask(int, const sigset_t * __restrict, sigset_t * __restrict); int sigsuspend(const sigset_t *); -/* XXX missing restrict qualifier. */ -int sigwait(const sigset_t *, int *); +int sigwait(const sigset_t * __restrict, int * __restrict); #endif #if __BSD_VISIBLE || __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 600 --- ./include/stdio.h.orig Mon Oct 7 20:34:41 2002 +++ ./include/stdio.h Mon Oct 7 20:43:41 2002 @@ -219,9 +219,6 @@ /* * Functions defined in ANSI C standard. * - * XXX fgetpos(), fgets(), fopen(), fputs(), fread(), freopen(), fscanf(), - * fwrite(), scanf(), sscanf(), vscanf(), and vsscanf() are missing the - * restrict type-qualifier. */ void clearerr(FILE *); int fclose(FILE *); @@ -229,19 +226,19 @@ int ferror(FILE *); int fflush(FILE *); int fgetc(FILE *); -int fgetpos(FILE *, fpos_t *); -char *fgets(char *, int, FILE *); -FILE *fopen(const char *, const char *); +int fgetpos(FILE * __restrict, fpos_t * __restrict); +char *fgets(char * __restrict, int, FILE * __restrict); +FILE *fopen(const char * __restrict, const char * __restrict); int fprintf(FILE * __restrict, const char * __restrict, ...); int fputc(int, FILE *); -int fputs(const char *, FILE *); -size_t fread(void *, size_t, size_t, FILE *); -FILE *freopen(const char *, const char *, FILE *); -int fscanf(FILE *, const char *, ...); +int fputs(const char * __restrict, FILE * __restrict); +size_t fread(void * __restrict, size_t, size_t, FILE * __restrict); +FILE *freopen(const char * __restrict, const char * __restrict, FILE * __restrict); +int fscanf(FILE * __restrict, const char * __restrict, ...); int fseek(FILE *, long, int); int fsetpos(FILE *, const fpos_t *); long ftell(FILE *); -size_t fwrite(const void *, size_t, size_t, FILE *); +size_t fwrite(const void * __restrict, size_t, size_t, FILE * __restrict); int getc(FILE *); int getchar(void); char *gets(char *); @@ -253,11 +250,11 @@ int remove(const char *); int rename(const char *, const char *); void rewind(FILE *); -int scanf(const char *, ...); +int scanf(const char * __restrict, ...); void setbuf(FILE * __restrict, char * __restrict); int setvbuf(FILE * __restrict, char * __restrict, int, size_t); int sprintf(char * __restrict, const char * __restrict, ...); -int sscanf(const char *, const char *, ...); +int sscanf(const char * __restrict, const char * __restrict, ...); FILE *tmpfile(void); char *tmpnam(char *); int ungetc(int, FILE *); @@ -270,10 +267,10 @@ #if __ISO_C_VISIBLE >= 1999 int snprintf(char * __restrict, size_t, const char * __restrict, ...) __printflike(3, 4); -int vscanf(const char *, __va_list) __scanflike(1, 0); +int vscanf(const char * __restrict, __va_list) __scanflike(1, 0); int vsnprintf(char * __restrict, size_t, const char * __restrict, __va_list) __printflike(3, 0); -int vsscanf(const char *, const char *, __va_list) +int vsscanf(const char * __restrict, const char * __restrict, __va_list) __scanflike(2, 0); /* --- ./lib/libc/gen/pselect.c.orig Mon Oct 7 19:33:27 2002 +++ ./lib/libc/gen/pselect.c Mon Oct 7 19:38:27 2002 @@ -47,8 +47,9 @@ * and allows the user to specify a signal mask to apply during the select. */ int -__pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, - const struct timespec *timo, const sigset_t *mask) +__pselect(int count, fd_set * __restrict rfds, fd_set * __restrict wfds, + fd_set * __restrict efds, const struct timespec * __restrict timo, + const sigset_t * __restrict mask) { sigset_t omask; struct timeval tvtimo, *tvp; --- ./lib/libc/gen/pselect.3.orig Mon Oct 7 19:38:49 2002 +++ ./lib/libc/gen/pselect.3 Mon Oct 7 19:39:19 2002 @@ -39,7 +39,7 @@ .Sh SYNOPSIS .In sys/select.h .Ft int -.Fn pselect "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set *exceptfds" "const struct timespec *timeout" "const sigset_t *newsigmask" +.Fn pselect "int nfds" "fd_set *restrict readfds" "fd_set *restrict writefds" "fd_set *restrict exceptfds" "const struct timespec *restrict timeout" "const sigset_t *restrict newsigmask" .Sh DESCRIPTION The .Fn pselect --- ./lib/libc/stdio/fgetpos.c.orig Mon Oct 7 20:30:52 2002 +++ ./lib/libc/stdio/fgetpos.c Mon Oct 7 20:32:25 2002 @@ -43,7 +43,7 @@ #include int -fgetpos(FILE *fp, fpos_t *pos) +fgetpos(FILE * __restrict fp, fpos_t * __restrict pos) { /* * ftello is thread-safe; no need to lock fp. --- ./lib/libc/stdio/fseek.3.orig Mon Oct 7 20:32:48 2002 +++ ./lib/libc/stdio/fseek.3 Mon Oct 7 20:33:05 2002 @@ -59,7 +59,7 @@ .Ft void .Fn rewind "FILE *stream" .Ft int -.Fn fgetpos "FILE *stream" "fpos_t *pos" +.Fn fgetpos "FILE *restrict stream" "fpos_t *restrict pos" .Ft int .Fn fsetpos "FILE *stream" "const fpos_t *pos" .In sys/types.h --- ./lib/libc/stdio/fgets.3.orig Mon Oct 7 20:46:48 2002 +++ ./lib/libc/stdio/fgets.3 Mon Oct 7 20:48:50 2002 @@ -48,7 +48,7 @@ .Sh SYNOPSIS .In stdio.h .Ft char * -.Fn fgets "char *str" "int size" "FILE *stream" +.Fn fgets "char *restrict str" "int size" "FILE *restrict stream" .Ft char * .Fn gets "char *str" .Sh DESCRIPTION @@ -162,4 +162,4 @@ and .Fn gets conform to -.St -isoC . +.St -isoC-99 . --- ./lib/libc/stdio/fopen.3.orig Mon Oct 7 20:49:23 2002 +++ ./lib/libc/stdio/fopen.3 Mon Oct 7 20:50:00 2002 @@ -49,7 +49,7 @@ .Sh SYNOPSIS .In stdio.h .Ft FILE * -.Fn fopen "const char *path" "const char *mode" +.Fn fopen "const char *restrict path" "const char *restrict mode" .Ft FILE * .Fn fdopen "int fildes" "const char *mode" .Ft FILE * --- ./lib/libc/stdio/fopen.c.orig Mon Oct 7 20:50:05 2002 +++ ./lib/libc/stdio/fopen.c Mon Oct 7 20:55:28 2002 @@ -52,8 +52,8 @@ FILE * fopen(file, mode) - const char *file; - const char *mode; + const char * __restrict file; + const char * __restrict mode; { FILE *fp; int f; --- ./lib/libc/stdio/fputs.c.orig Mon Oct 7 20:56:00 2002 +++ ./lib/libc/stdio/fputs.c Mon Oct 7 20:56:41 2002 @@ -53,8 +53,8 @@ */ int fputs(s, fp) - const char *s; - FILE *fp; + const char * __restrict s; + FILE * __restrict fp; { int retval; struct __suio uio; --- ./lib/libc/stdio/fread.3.orig Mon Oct 7 20:57:04 2002 +++ ./lib/libc/stdio/fread.3 Mon Oct 7 20:58:32 2002 @@ -48,9 +48,9 @@ .Sh SYNOPSIS .In stdio.h .Ft size_t -.Fn fread "void *ptr" "size_t size" "size_t nmemb" "FILE *stream" +.Fn fread "void *restrict ptr" "size_t size" "size_t nmemb" "FILE *restrict stream" .Ft size_t -.Fn fwrite "const void *ptr" "size_t size" "size_t nmemb" "FILE *stream" +.Fn fwrite "const void *restrict ptr" "size_t size" "size_t nmemb" "FILE *restrict stream" .Sh DESCRIPTION The function .Fn fread --- ./lib/libc/stdio/fread.c.orig Mon Oct 7 20:59:05 2002 +++ ./lib/libc/stdio/fread.c Mon Oct 7 20:59:23 2002 @@ -49,9 +49,9 @@ size_t fread(buf, size, count, fp) - void *buf; + void * __restrict buf; size_t size, count; - FILE *fp; + FILE * __restrict fp; { size_t resid; char *p; --- ./lib/libc/stdio/freopen.c.orig Mon Oct 7 20:59:37 2002 +++ ./lib/libc/stdio/freopen.c Mon Oct 7 21:00:35 2002 @@ -59,7 +59,8 @@ */ FILE * freopen(file, mode, fp) - const char *file, *mode; + const char * __restrict file; + const char * __restrict mode; FILE *fp; { int f; --- ./lib/libc/stdio/fscanf.c.orig Mon Oct 7 21:00:48 2002 +++ ./lib/libc/stdio/fscanf.c Mon Oct 7 21:01:01 2002 @@ -47,7 +47,7 @@ #include "libc_private.h" int -fscanf(FILE *fp, char const *fmt, ...) +fscanf(FILE * __restrict fp, char const * __restrict fmt, ...) { int ret; va_list ap; --- ./lib/libc/stdio/scanf.3.orig Mon Oct 7 21:01:15 2002 +++ ./lib/libc/stdio/scanf.3 Mon Oct 7 21:02:44 2002 @@ -52,18 +52,18 @@ .Sh SYNOPSIS .In stdio.h .Ft int -.Fn scanf "const char *format" ... +.Fn scanf "const char *restrict format" ... .Ft int -.Fn fscanf "FILE *stream" "const char *format" ... +.Fn fscanf "FILE *restrict stream" "const char *restrict format" ... .Ft int -.Fn sscanf "const char *str" "const char *format" ... +.Fn sscanf "const char *restrict str" "const char *restrict format" ... .In stdarg.h .Ft int -.Fn vscanf "const char *format" "va_list ap" +.Fn vscanf "const char *restrict format" "va_list ap" .Ft int -.Fn vsscanf "const char *str" "const char *format" "va_list ap" +.Fn vsscanf "const char *restrict str" "const char *restrict format" "va_list ap" .Ft int -.Fn vfscanf "FILE *stream" "const char *format" "va_list ap" +.Fn vfscanf "FILE *restrict stream" "const char *restrict format" "va_list ap" .Sh DESCRIPTION The .Fn scanf --- ./lib/libc/stdio/vscanf.c.orig Mon Oct 7 21:02:59 2002 +++ ./lib/libc/stdio/vscanf.c Mon Oct 7 21:03:16 2002 @@ -47,7 +47,7 @@ int vscanf(fmt, ap) - const char *fmt; + const char * __restrict fmt; __va_list ap; { int retval; --- ./lib/libc/stdio/vsscanf.c.orig Mon Oct 7 21:03:26 2002 +++ ./lib/libc/stdio/vsscanf.c Mon Oct 7 21:03:45 2002 @@ -60,8 +60,8 @@ int vsscanf(str, fmt, ap) - const char *str; - const char *fmt; + const char * __restrict str; + const char * __restrict fmt; __va_list ap; { FILE f; --- ./lib/libc/stdio/sscanf.c.orig Mon Oct 7 21:03:54 2002 +++ ./lib/libc/stdio/sscanf.c Mon Oct 7 21:04:14 2002 @@ -59,7 +59,7 @@ } int -sscanf(const char *str, char const *fmt, ...) +sscanf(const char * __restrict str, char const * __restrict fmt, ...) { int ret; va_list ap; --- ./lib/libc/stdio/fwrite.c.orig Mon Oct 7 21:04:26 2002 +++ ./lib/libc/stdio/fwrite.c Mon Oct 7 21:04:42 2002 @@ -53,9 +53,9 @@ */ size_t fwrite(buf, size, count, fp) - const void *buf; + const void * __restrict buf; size_t size, count; - FILE *fp; + FILE * __restrict fp; { size_t n; struct __suio uio; --- ./lib/libc/stdio/scanf.c.orig Mon Oct 7 21:06:14 2002 +++ ./lib/libc/stdio/scanf.c Mon Oct 7 21:06:29 2002 @@ -47,7 +47,7 @@ #include "libc_private.h" int -scanf(char const *fmt, ...) +scanf(char const * __restrict fmt, ...) { int ret; va_list ap; --a8Wt8u1KmwUX3Y2C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Oct 8 11: 0:12 2002 Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2972B37B401 for ; Tue, 8 Oct 2002 11:00:10 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC0D43E6E for ; Tue, 8 Oct 2002 11:00:09 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g98I09Co065654 for ; Tue, 8 Oct 2002 11:00:09 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g98I09OG065653; Tue, 8 Oct 2002 11:00:09 -0700 (PDT) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6963E37B406 for ; Tue, 8 Oct 2002 10:56:25 -0700 (PDT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEF1D43E3B for ; Tue, 8 Oct 2002 10:56:24 -0700 (PDT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.6/8.12.6) with ESMTP id g98HuO7R047878 for ; Tue, 8 Oct 2002 10:56:24 -0700 (PDT) (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.6/8.12.6/Submit) id g98HuOdn047877; Tue, 8 Oct 2002 10:56:24 -0700 (PDT) Message-Id: <200210081756.g98HuOdn047877@www.freebsd.org> Date: Tue, 8 Oct 2002 10:56:24 -0700 (PDT) From: Jim Mercer To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: standards/43837: PKST (pakistan daylight time) changed from Oct 15 to Oct 5 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 >Number: 43837 >Category: standards >Synopsis: PKST (pakistan daylight time) changed from Oct 15 to Oct 5 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 08 11:00:09 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Jim Mercer >Release: -stable >Organization: Reptilian Research >Environment: FreeBSD iguana.reptiles.org 4.7-RC FreeBSD 4.7-RC #31: Wed Oct 2 11:42:50 EDT 2002 root@iguana.reptiles.org:/usr/obj/usr/src/sys/IGUANA i386 >Description: currently, /usr/src/zoneinfo/asia lists PKST as changing back on Oct 15. that has apparently been changed to Oct 5. while i can't find any "official" webpage, the following URL has some discussion of the change http://www.jang.com.pk/thenews/oct2002-weekly/nos-06-10-2002/she.htm#3 >How-To-Repeat: TZ=/usr/share/zoneinfo/Asia/Karachi ; export TZ echo -n "`basename $TZ`|" ; date >Fix: change /usr/src/share/zoneinfo/asia from: Rule Pakistan 2002 max - Oct 15 0:00 0 - to: Rule Pakistan 2002 max - Oct 5 0:00 0 - >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Oct 8 11:39:11 2002 Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D83637B401; Tue, 8 Oct 2002 11:39:11 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E7743E4A; Tue, 8 Oct 2002 11:39:10 -0700 (PDT) (envelope-from mike@FreeBSD.org) Received: from freefall.freebsd.org (mike@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g98IdACo083958; Tue, 8 Oct 2002 11:39:10 -0700 (PDT) (envelope-from mike@freefall.freebsd.org) Received: (from mike@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g98IdAQt083954; Tue, 8 Oct 2002 11:39:10 -0700 (PDT) Date: Tue, 8 Oct 2002 11:39:10 -0700 (PDT) From: Mike Barcroft Message-Id: <200210081839.g98IdAQt083954@freefall.freebsd.org> To: mike@FreeBSD.org, freebsd-standards@FreeBSD.org, wollman@FreeBSD.org Subject: Re: standards/43837: PKST (pakistan daylight time) changed from Oct 15 to Oct 5 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 Synopsis: PKST (pakistan daylight time) changed from Oct 15 to Oct 5 Responsible-Changed-From-To: freebsd-standards->wollman Responsible-Changed-By: mike Responsible-Changed-When: Tue Oct 8 11:38:12 PDT 2002 Responsible-Changed-Why: Over to Garrett Wollman. http://www.freebsd.org/cgi/query-pr.cgi?pr=43837 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Oct 9 19:22:30 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 6BB3337B401; Wed, 9 Oct 2002 19:22:28 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB37E43E4A; Wed, 9 Oct 2002 19:22:27 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9A2N8CK010097; Wed, 9 Oct 2002 22:23:08 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9A2N8Ed010096; Wed, 9 Oct 2002 22:23:08 -0400 (EDT) Date: Wed, 9 Oct 2002 22:23:07 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Problem detecting POSIX symbolic constants Message-ID: <20021009222307.A9894@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 Hi, Earlier this year on the FreeBSD hackers mailing list: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers I was advised by Terry Lambert to use: #ifdef _POSIX_REALTIME_SIGNALS to detect if sigqueue(), sigtimedwait, sigwaitinfo() were defined. I made this change to the FreeBSD configuration for ACE, a C++ library used for systems programming ( http://www.cs.wustl.edu/~schmidt/ACE.html ). The change I made worked fine in -STABLE. However, in -CURRENT, this test breaks, because _POSIX_REALTIME_SIGNALS is defined, but it is -1. According to the letter of the law: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html "The following symbolic constants shall either be undefined or defined with a value other than -1." So, this is legal way to implement these macros. It just breaks my code. :) Can I appeal to the freebsd-standards team to leave these macros undefined instead of defining them to -1? #ifdef/#ifndef is a pretty common way to detect if a feature is available on a system, especially when used in conjunction with something like autoconf. If that is not an option, then what is the correct way for me to write my code? Keep in mind that code in ACE must be very portable, and work on platforms which may not adhere 100% to the letter of the POSIX law. Unfortunately ACE does not use autoconf, so these configurations need to be hardcoded. Here is my code, from config-freebsd-pthread.h from ACE: 210 #include 211 #include 212 /* POSIX Realtime signals are not fully implemented in FreeBSD. 213 When they are implemented, then _POSIX_REALTIME_SIGNALS will be 214 defined, as specified in the POSIX standard. 215 Refer to e-mail thread on freebsd-hackers mailing list, March 2002. */ 216 #ifdef _POSIX_REALTIME_SIGNALS 217 # define ACE_HAS_AIO_CALLS 218 # ifndef SIGRTMIN 219 # define SIGRTMIN 32 220 # endif /* SIGRTMIN */ 221 # ifndef SIGRTMAX 222 # define SIGRTMAX (_SIG_MAXSIG - 1) 223 # endif /* SIGRTMAX */ 224 #endif /* _POSIX_REALTIME_SIGNALS */ Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Oct 9 19:32:19 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 A459B37B401; Wed, 9 Oct 2002 19:32:17 -0700 (PDT) Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F00E43E4A; Wed, 9 Oct 2002 19:32:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0018.cvx21-bradley.dialup.earthlink.net ([209.179.192.18] helo=mindspring.com) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17zT7V-0000q7-00; Wed, 09 Oct 2002 19:32:13 -0700 Message-ID: <3DA4E61C.DCC8F543@mindspring.com> Date: Wed, 09 Oct 2002 19:29:48 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Craig Rodrigues Cc: freebsd-standards@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem detecting POSIX symbolic constants References: <20021009222307.A9894@attbi.com> 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 Craig Rodrigues wrote: > #ifdef _POSIX_REALTIME_SIGNALS > According to the letter of the law: > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html > > "The following symbolic constants shall either be undefined or defined > with a value other than -1." > > So, this is legal way to implement these macros. It just breaks my code. :) Crap. I missed that. To be totally correct, you will need to: #ifdef _POSIX_REALTIME_SIGNALS #if (_POSIX_REALTIME_SIGNALS != -1) ... #endif #endif It's annoying, but doing this will ensure that there are no gaps through which some system other than FreeBSD might fall. > If that is not an option, then what is the correct way for me to write > my code? Keep in mind that code in ACE must be very portable, and work > on platforms which may not adhere 100% to the letter of the POSIX law. This argues for two tests, instead of one. Sorry. PS: There is probably a technicality for wehther or not the "#if" directive is supported, seperately from the value compare. PPS: Technically, it doesn't say that the defined value has to be an integer type, either... some people are just jerks. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Oct 9 20:20:18 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 842AA37B401; Wed, 9 Oct 2002 20:20:16 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 726A543E4A; Wed, 9 Oct 2002 20:20:15 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9A3KuCK010445; Wed, 9 Oct 2002 23:20:56 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9A3KuIh010444; Wed, 9 Oct 2002 23:20:56 -0400 (EDT) Date: Wed, 9 Oct 2002 23:20:56 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021009232056.A10429@attbi.com> References: <20021009222307.A9894@attbi.com> <3DA4E61C.DCC8F543@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DA4E61C.DCC8F543@mindspring.com>; from tlambert2@mindspring.com on Wed, Oct 09, 2002 at 07:29:48PM -0700 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 On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote: > To be totally correct, you will need to: > > #ifdef _POSIX_REALTIME_SIGNALS > #if (_POSIX_REALTIME_SIGNALS != -1) > > ... > > #endif > #endif > > It's annoying, but doing this will ensure that there are no > gaps through which some system other than FreeBSD might fall. Sigh. Why did the POSIX guys do this? :( BTW, I think that: #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS != -1 ) should suffice, but I'll double-check with one of my portability gurus to see if that is OK for ACE. I have another request. Even though my preprocessor check was bogus, ACE still compiled, and I did not discover that there were any problems until link time, ie. I had a libACE.so library which could not link with anything because of unresolved symbols. This was very annoying. It would have been nicer if this could have been caught earlier in the compile stage. Since sigqueue(), sigwait(), sigwaitinfo() are not implemented in FreeBSD, is this patch OK? --- src/include/signal.h.orig Wed Oct 9 23:15:21 2002 +++ src/include/signal.h Wed Oct 9 23:15:31 2002 @@ -76,13 +76,6 @@ int sigwait(const sigset_t *, int *); #endif -#if __BSD_VISIBLE || __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 600 -int sigqueue(__pid_t, int, const union sigval); -int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, - const struct timespec * __restrict); -int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); -#endif - #if __BSD_VISIBLE || __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE int killpg(__pid_t, int); int sigaltstack(const stack_t * __restrict, stack_t * __restrict); At some point in the future when POSIX RT signals are implemented in FreeBSD (I'm not volunteering :), then _POSIX_REALTIME_SIGNALS can be defined to 200112L in unistd.h, and these three prototypes can be put back into . Is this OK? Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Oct 9 22:49:22 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 CDA1837B401; Wed, 9 Oct 2002 22:49:19 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83C4B43E4A; Wed, 9 Oct 2002 22:49:18 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g9A5nGgQ060519 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 10 Oct 2002 01:49:16 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g9A5nFLn060516; Thu, 10 Oct 2002 01:49:15 -0400 (EDT) (envelope-from wollman) Date: Thu, 10 Oct 2002 01:49:15 -0400 (EDT) From: Garrett Wollman Message-Id: <200210100549.g9A5nFLn060516@khavrinen.lcs.mit.edu> To: Craig Rodrigues Cc: freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Problem detecting POSIX symbolic constants In-Reply-To: <20021009222307.A9894@attbi.com> References: <20021009222307.A9894@attbi.com> 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 < said: > I was advised by Terry Lambert to use: > #ifdef _POSIX_REALTIME_SIGNALS Terry was wrong. If _POSIX_REALTIME_SIGNALS is undefined, it means one of two things: - The RTS option is not supported, or - You can't tell whether or not the RTS option is supported. The section of XBD you quoted refers only to the two symbolic onstants listed in that bullet point: _POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC. Both of these represent options from older version of POSIX which are now mandatory (which is also true of the following bullet-point). This change was made in POSIX.1-2001 for alignment with the FIPS-151 standard. > The change I made worked fine in -STABLE. > However, in -CURRENT, this test breaks, because _POSIX_REALTIME_SIGNALS > is defined, but it is -1. POSIX.1-2001 requires that this constant be so defined if the option is not supported. See the section. > Can I appeal to the freebsd-standards team to leave these macros undefined > instead of defining them to -1? #ifdef/#ifndef is a pretty common way > to detect if a feature is available on a system, especially when used > in conjunction with something like autoconf. It's also wrong when used in conjunction with POSIX options. The correct test is as follows: If the option constant is not defined, you really have no idea whether the option is available or not. If the corresponding sysconf(3) key *is* defined, then you might be able to use sysconf(3) or getconf(1) to determine whether the option is supported. You will probably still need to check for the headers and functions manually, because the implementation is not being forthcoming and probably doesn't implement the function even if sysconf() claims it does. If the option constant is defined as -1, the option is guaranteed not to be supported, and the implementation provides neither the library functions nor the header files necessary to compile a program which makes use of the option. If the option constant is defined as a positive value, the option is guaranteed to be supported under all configurations of the system. The library functions and header files are supplied for use with the C compiler, c99(1) (or c89(1) for older POSIX standards). For some functions, additional library specifications must be provided on the c99 command line (see the standard for details). The precise valu of the option constant will tell you what version of the option is supported; for POSIX.1-2001, the option constant if positive must usually be defined to 200112L. If the option constant is defined but zero, the option may or may not be supported depending on run-time configuration. Library functions and header files are supplied as described in the previous case, but applications must call sysconf(3) with the appropriate key to determine at run time whether the option is supported on the system as currently configured. These rules have changed somewhat as the POSIX standards have evolved, but this is the current state of affairs as set out in 1003.1-2001. Hope this helps. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 1: 9:28 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 F383537B401; Thu, 10 Oct 2002 01:09:25 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81C4743EAC; Thu, 10 Oct 2002 01:09:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0055.cvx40-bradley.dialup.earthlink.net ([216.244.42.55] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17zYNL-0005Bj-00; Thu, 10 Oct 2002 01:08:55 -0700 Message-ID: <3DA5354F.9BB3E54B@mindspring.com> Date: Thu, 10 Oct 2002 01:07:43 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: Craig Rodrigues , freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Problem detecting POSIX symbolic constants References: <20021009222307.A9894@attbi.com> <200210100549.g9A5nFLn060516@khavrinen.lcs.mit.edu> 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 Garrett Wollman wrote: > < said: > > I was advised by Terry Lambert to use: > > #ifdef _POSIX_REALTIME_SIGNALS > > Terry was wrong. If _POSIX_REALTIME_SIGNALS is undefined, it means > one of two things: > > - The RTS option is not supported, or That's what I said in the orignal posting. He needed to protect his use of the covered functions with that. [ ... ] > POSIX.1-2001 requires that this constant be so defined if the option > is not supported. See the section. Is FreeBSD fully compliant with POSIX 1003.1-2001 compliant? > The correct test is as follows: > > If the option constant is not defined, you really have no idea whether > the option is available or not. If the corresponding sysconf(3) key > *is* defined, then you might be able to use sysconf(3) or getconf(1) > to determine whether the option is supported. You will probably still > need to check for the headers and functions manually, because the > implementation is not being forthcoming and probably doesn't implement > the function even if sysconf() claims it does. Manual checking is no good. The only way to do that without relying on a feature test macro in FreeBSD is to nm the library, and look for the function symbols, or try linking a stub program, and check the exit status. FreeBSD has the prototypes, but doesn't have the code implementing the functions, which is where the probem started. It's a lot easier to check the macro: you don't have to write scripts to have portable source code. > If the option constant is defined as -1, the option is guaranteed not > to be supported, and the implementation provides neither the library > functions nor the header files necessary to compile a program which > makes use of the option. > > If the option constant is defined as a positive value, the option is > guaranteed to be supported under all configurations of the system. So the test is: #ifdef _POSIX_REALTIME_SIGNALS #if _POSIX_REALTIME_SIGNALS > 0 ...or, if you want to assume all preprocessors support "#if": #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS > 0) I think the first is safer, in that if "#if" is not supported, it being an undefined preprocessor directive would be non-fatal, being in an uncompiled "#ifdef" block... > If the option constant is defined but zero, the option may or may not > be supported depending on run-time configuration. Library functions > and header files are supplied as described in the previous case, but > applications must call sysconf(3) with the appropriate key to > determine at run time whether the option is supported on the system as > currently configured. Out of curiosity, where in the standard does it say this about zero? > These rules have changed somewhat as the POSIX standards have evolved, > but this is the current state of affairs as set out in 1003.1-2001. > > Hope this helps. Yes, it clarifies things a lot. I wish you'd spoken up when he was originally asking how to perform the feature test at compile time (the sysconf(3) stuff for runtime support is pretty useless, IMO... you would fall back to not using the interface, I think, rather than put in a whole alternate set of code for it, with a whole alternate set of runtime overhead, which might add a bunch of compares to a "feature exists" flag). My posting was based on the information present in FreeBSD source files at the time the question was asked (and it's worked well, until -current defined it to be -1, without being otherwise fully compliant with POSIX 1003.1-2001, Grrrrr...). Would you recommend "#if", even though it meant the code would be less portable? The ACE framework is supposed to be portable to a lot of systems, some of which are running older compliers or not GNU C++. I'm positive that the first couple of years of the Oregon C++ compiler preprocessor didn't support "#if", for example. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 4:21:58 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 22D9B37B401; Thu, 10 Oct 2002 04:21:55 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF9F143E9E; Thu, 10 Oct 2002 04:21:53 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA08746; Thu, 10 Oct 2002 21:21:47 +1000 Date: Thu, 10 Oct 2002 21:31:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Craig Rodrigues Cc: freebsd-standards@FreeBSD.ORG, Subject: Re: Problem detecting POSIX symbolic constants In-Reply-To: <20021009232056.A10429@attbi.com> Message-ID: <20021010205529.M8598-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 9 Oct 2002, Craig Rodrigues wrote: > On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote: > > To be totally correct, you will need to: > > > > #ifdef _POSIX_REALTIME_SIGNALS > > #if (_POSIX_REALTIME_SIGNALS != -1) > > > > ... > > > > #endif > > #endif > > > > It's annoying, but doing this will ensure that there are no > > gaps through which some system other than FreeBSD might fall. In Standard C, this is equivalent to the non-verbose version: #if _POSIX_REALTIME_SIGNALS != -1 ... #endif since if _POSIX_REALTIME_SIGNALS is not defined then it is equivalent to 0 in cpp expressions. The problem cases are if _POSIX_REALTIME_SIGNALS is defined to or , but these are not permitted in POSIX.1-2001. These cases were permitted for many feature test macros in POSIX.1-1990. > Sigh. Why did the POSIX guys do this? :( Perhaps because they wanted you to use sysconf() instead of these mistakes. Actually, they didn't do this. _POSIX_REALTIME_SIGNALS is specified to have value 0, -1 or 200xxxL (draft 7 says xxx; I think the final standard says 112). > BTW, I think that: > #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS != -1 ) > > should suffice, but I'll double-check with one of my portability gurus > to see if that is OK for ACE. This is variant of the above verbose version. It requires slightly more modern compilers, so it might fail for some 20-year old pre-Standard C compilers instead of only for some 25-year old ones. > I have another request. Even though my preprocessor check was bogus, > ACE still compiled, and I did not discover that there were any problems > until link time, ie. I had a libACE.so library which could not > link with anything because of unresolved symbols. This was very annoying. > It would have been nicer if this could have been caught earlier in the > compile stage. > Since sigqueue(), sigwait(), sigwaitinfo() are not implemented in FreeBSD, > is this patch OK? > > --- src/include/signal.h.orig Wed Oct 9 23:15:21 2002 > +++ src/include/signal.h Wed Oct 9 23:15:31 2002 > @@ -76,13 +76,6 @@ > int sigwait(const sigset_t *, int *); > #endif > > -#if __BSD_VISIBLE || __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 600 > -int sigqueue(__pid_t, int, const union sigval); > -int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, > - const struct timespec * __restrict); > -int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); > -#endif > - > #if __BSD_VISIBLE || __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE > int killpg(__pid_t, int); > int sigaltstack(const stack_t * __restrict, stack_t * __restrict); > > At some point in the future when POSIX RT signals are implemented > in FreeBSD (I'm not volunteering :), then > _POSIX_REALTIME_SIGNALS can be defined to 200112L in unistd.h, and > these three prototypes can be put back into . > > Is this OK? I used a variant your patch for this in PR 35924 until recently when I noticed that it usually worked for the bogus reason that is not included, then _POSIX_REALTIME_SIGNALS is only defined accidentally (to whatever value). I now use just #if 0 and an XXX comment as a reminder to fix this someday: %%% Index: signal.h =================================================================== RCS file: /home/ncvs/src/include/signal.h,v retrieving revision 1.19 diff -u -2 -r1.19 signal.h --- signal.h 6 Oct 2002 21:54:08 -0000 1.19 +++ signal.h 7 Oct 2002 07:06:19 -0000 @@ -78,9 +79,18 @@ #if __BSD_VISIBLE || __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 600 +#if 0 +/* + * PR: 35924 + * XXX we don't actually have these. We set _POSIX_REALTIME_SIGNALS to + * -1 to show that we don't have them, but this symbol is not necessarily + * in scope (in the current implementation), so we can't use it here. + */ int sigqueue(__pid_t, int, const union sigval); +struct timespec; int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, const struct timespec * __restrict); int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); #endif +#endif #if __BSD_VISIBLE || __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE %%% The patch also moves the forward declaration of struct timespec near to the one place that it is used (related patches not included). This mainly makes it obvious that the messy visibility for it is the same as the one for the function that uses it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 5: 3:36 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 ACA0A37B401; Thu, 10 Oct 2002 05:03:34 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98DA543E8A; Thu, 10 Oct 2002 05:03:33 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA12387; Thu, 10 Oct 2002 22:03:28 +1000 Date: Thu, 10 Oct 2002 22:13:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Craig Rodrigues Cc: freebsd-standards@FreeBSD.ORG, Subject: Re: Problem detecting POSIX symbolic constants In-Reply-To: <20021009222307.A9894@attbi.com> Message-ID: <20021010213351.X8598-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 9 Oct 2002, Craig Rodrigues wrote: > Earlier this year on the FreeBSD hackers mailing list: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers > > I was advised by Terry Lambert to use: > #ifdef _POSIX_REALTIME_SIGNALS > > to detect if sigqueue(), sigtimedwait, sigwaitinfo() were defined. > > I made this change to the FreeBSD configuration for ACE, a C++ > library used for systems programming ( http://www.cs.wustl.edu/~schmidt/ACE.html ). > > The change I made worked fine in -STABLE. > However, in -CURRENT, this test breaks, because _POSIX_REALTIME_SIGNALS > is defined, but it is -1. > > According to the letter of the law: > http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html > > "The following symbolic constants shall either be undefined or defined > with a value other than -1." This law only covers 2 symbols (_POSIX_CHOWN_RESTRICTED and _POSIX_NO_TRUNC). _POSIX_REALTIME_SIGNALS is covered by more general and complicated laws. It may be undefined or defined to 0, -1 or 2001mumbleL. > So, this is legal way to implement these macros. It just breaks my code. :) > > Can I appeal to the freebsd-standards team to leave these macros undefined > instead of defining them to -1? #ifdef/#ifndef is a pretty common way > to detect if a feature is available on a system, especially when used > in conjunction with something like autoconf. No. If they were undefined (and _POSIX_VERSION is large enough), then their undefinedness means that applications must use sysconf() to determine if they work. Other cases are simpler: _POSIX_REALTIME_SIGNALS is defined to -1: This means that the interface is not supported. Applications shouldn't use it at either compile time, link time or runtime, since it might not exist in headers or libraries. _POSIX_REALTIME_SIGNALS is defined to 0: This means that the interface may work, and that it exists in headers and libraries, so applications may reference it in normal ways. It may fail at runtime; applications must use sysconf() to determine if it is actually _POSIX_REALTIME_SIGNALS is defined to 2001mumbleL: This means that the interface just works. sysconf() may be used to check that it works, but sysconf() must not fail. _POSIX_REALTIME_SIGNALS is undefined: Apparently the same as when it is defined to 0, except you cannot assume that anything related to it works until you call sysconf(), so you must not reference its interfaces statically, and must use a dll or something that references it. The dll is presumably available on systems that support it but not (except possibly a dummy version) on systems that don't support it. I think the case where the symbol is undefined should never be implemented in practice. It can be reduced to the case where the symbol is 0 using dynamic linkage with the complications for linkage not visible to the application. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 5: 8:15 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 0584F37B404 for ; Thu, 10 Oct 2002 05:08:12 -0700 (PDT) Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 1D38443E9E for ; Thu, 10 Oct 2002 05:08:10 -0700 (PDT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 4100 invoked from network); 10 Oct 2002 12:01:10 -0000 Received: from upnet-dialinpool-103.upnet.gr (HELO hades.hell.gr) (@150.140.128.151) by nic.upatras.gr with SMTP; 10 Oct 2002 12:01:10 -0000 Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.6/8.12.6) with ESMTP id g9AC894w041390; Thu, 10 Oct 2002 15:08:11 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by hades.hell.gr (8.12.6/8.12.6/Submit) id g9ABOZjf036551; Thu, 10 Oct 2002 14:24:35 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 10 Oct 2002 14:24:34 +0300 From: Giorgos Keramidas To: Terry Lambert Cc: Garrett Wollman , Craig Rodrigues , freebsd-standards@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021010112434.GS21391@hades.hell.gr> References: <20021009222307.A9894@attbi.com> <200210100549.g9A5nFLn060516@khavrinen.lcs.mit.edu> <3DA5354F.9BB3E54B@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA5354F.9BB3E54B@mindspring.com> X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6 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 On 2002-10-10 01:07, Terry Lambert wrote: > > So the test is: > > #ifdef _POSIX_REALTIME_SIGNALS > #if _POSIX_REALTIME_SIGNALS > 0 > > ...or, if you want to assume all preprocessors support "#if": > > #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS > 0) > > I think the first is safer, in that if "#if" is not supported, it > being an undefined preprocessor directive would be non-fatal, > being in an uncompiled "#ifdef" block... Well, almost. There is one exception. A compiler that doesn't support #if but happens to run in an environment that has _POSIX_REALTIME_SIGNALS defined and equal to -1. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 7:58:10 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 31CEB37B40A; Thu, 10 Oct 2002 07:58:01 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921A34433D; Thu, 10 Oct 2002 07:55:28 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9AEtWCK012415; Thu, 10 Oct 2002 10:55:32 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9AEtVHC012414; Thu, 10 Oct 2002 10:55:31 -0400 (EDT) Date: Thu, 10 Oct 2002 10:55:31 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021010105531.A12354@attbi.com> References: <20021009232056.A10429@attbi.com> <20021010205529.M8598-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021010205529.M8598-100000@gamplex.bde.org>; from bde@zeta.org.au on Thu, Oct 10, 2002 at 09:31:56PM +1000 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 On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote: > Perhaps because they wanted you to use sysconf() instead of these mistakes. Well in the case of ACE, it is a C++ library that is compiled on platforms which may or may not have sysconf() (ie. Windows), so using sysconf() is not practical in this case. Checking a feature macro is much easier. > > This is variant of the above verbose version. It requires slightly more > modern compilers, so it might fail for some 20-year old pre-Standard C > compilers instead of only for some 25-year old ones. ACE makes some pretty aggressive use of C++ features, so luckily compliance with 20-25 year old compilers is not a requirement. :) Support for gcc 2.7.2 and 2.8 compilers was dropped recently. It will be really exciting to use ACE on FreeBSD 5.x since gcc 3.2.1 has some fairly good support for modern C++ features. > I used a variant your patch for this in PR 35924 until recently when Wow, I forgot that I filed 35924! :) Thanks for reminding me. > I noticed that it usually worked for the bogus reason that > is not included, then _POSIX_REALTIME_SIGNALS is only defined accidentally > (to whatever value). I now use just #if 0 and an XXX comment as a > reminder to fix this someday: > > %%% > Index: signal.h > =================================================================== > RCS file: /home/ncvs/src/include/signal.h,v > retrieving revision 1.19 > diff -u -2 -r1.19 signal.h > --- signal.h 6 Oct 2002 21:54:08 -0000 1.19 > +++ signal.h 7 Oct 2002 07:06:19 -0000 > @@ -78,9 +79,18 @@ > > #if __BSD_VISIBLE || __POSIX_VISIBLE >= 199506 || __XSI_VISIBLE >= 600 > +#if 0 > +/* > + * PR: 35924 > + * XXX we don't actually have these. We set _POSIX_REALTIME_SIGNALS to > + * -1 to show that we don't have them, but this symbol is not necessarily > + * in scope (in the current implementation), so we can't use it here. > + */ > int sigqueue(__pid_t, int, const union sigval); > +struct timespec; > int sigtimedwait(const sigset_t * __restrict, siginfo_t * __restrict, > const struct timespec * __restrict); > int sigwaitinfo(const sigset_t * __restrict, siginfo_t * __restrict); > #endif > +#endif > > #if __BSD_VISIBLE || __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE > %%% > > The patch also moves the forward declaration of struct timespec near to > the one place that it is used (related patches not included). This > mainly makes it obvious that the messy visibility for it is the same > as the one for the function that uses it. This patch works for me. I think it is just as easy to just remove cruft from the header file entirely, but since your patch effectively does the same thing and has informative comments, that is fine. If your patch (or some equivalent variant) is committed, then I think PR 35924 can be closed. Something needs to be done about these prototypes. Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 12:28:45 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 49CD737B401; Thu, 10 Oct 2002 12:28:44 -0700 (PDT) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1E1143E4A; Thu, 10 Oct 2002 12:28:43 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0397.cvx21-bradley.dialup.earthlink.net ([209.179.193.142] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ziyR-0001f6-00; Thu, 10 Oct 2002 12:27:55 -0700 Message-ID: <3DA5D473.21A43EDD@mindspring.com> Date: Thu, 10 Oct 2002 12:26:43 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giorgos Keramidas Cc: Garrett Wollman , Craig Rodrigues , freebsd-standards@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem detecting POSIX symbolic constants References: <20021009222307.A9894@attbi.com> <200210100549.g9A5nFLn060516@khavrinen.lcs.mit.edu> <3DA5354F.9BB3E54B@mindspring.com> <20021010112434.GS21391@hades.hell.gr> 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 Giorgos Keramidas wrote: > > I think the first is safer, in that if "#if" is not supported, it > > being an undefined preprocessor directive would be non-fatal, > > being in an uncompiled "#ifdef" block... > > Well, almost. There is one exception. A compiler that doesn't support > #if but happens to run in an environment that has _POSIX_REALTIME_SIGNALS > defined and equal to -1. You can always wrap the whole thing with a POSIX test, which would dictate the preprocessor support, as well, I think. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 12:33:35 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 14F2D37B401; Thu, 10 Oct 2002 12:33:34 -0700 (PDT) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id A638C43E97; Thu, 10 Oct 2002 12:33:33 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0397.cvx21-bradley.dialup.earthlink.net ([209.179.193.142] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17zj3k-00034J-00; Thu, 10 Oct 2002 12:33:25 -0700 Message-ID: <3DA5D5BD.1DAFF031@mindspring.com> Date: Thu, 10 Oct 2002 12:32:13 -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: <20021010205529.M8598-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: > In Standard C, this is equivalent to the non-verbose version: > > #if _POSIX_REALTIME_SIGNALS != -1 > ... > #endif > > since if _POSIX_REALTIME_SIGNALS is not defined then it is equivalent to > 0 in cpp expressions. The problem cases are if _POSIX_REALTIME_SIGNALS > is defined to or , but these are not permitted in > POSIX.1-2001. These cases were permitted for many feature test macros > in POSIX.1-1990. I know it's not fashionable to write code that's portable to compilers other than GCC, but even if FreeBSD is going to ignore portability for it's own source code, it's probably unreasonable to expect ACE to ignore portability for theirs. > > Sigh. Why did the POSIX guys do this? :( > > Perhaps because they wanted you to use sysconf() instead of these mistakes. > Actually, they didn't do this. _POSIX_REALTIME_SIGNALS is specified to > have value 0, -1 or 200xxxL (draft 7 says xxx; I think the final standard > says 112). This can't be the case; specifically, the sysconf() test will only work at runtime, which means that the symbols had to be there and resolvable at link time. Unless you know some preprocessor directive to access the "sysconf" space? > > BTW, I think that: > > #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS != -1 ) > > > > should suffice, but I'll double-check with one of my portability gurus > > to see if that is OK for ACE. > > This is variant of the above verbose version. It requires slightly more > modern compilers, so it might fail for some 20-year old pre-Standard C > compilers instead of only for some 25-year old ones. Uh, the 1990 standard, which allowed "#if" is only 12 years old. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Oct 10 12:39:59 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 EDFAE37B401; Thu, 10 Oct 2002 12:39:57 -0700 (PDT) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DA6D43E9E; Thu, 10 Oct 2002 12:39:57 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0397.cvx21-bradley.dialup.earthlink.net ([209.179.193.142] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17zjA0-00067e-00; Thu, 10 Oct 2002 12:39:53 -0700 Message-ID: <3DA5D741.FB59AE1B@mindspring.com> Date: Thu, 10 Oct 2002 12:38:41 -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: <20021010213351.X8598-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 defined to 0: > This means that the interface may work, and that it exists in headers and > libraries, so applications may reference it in normal ways. It may fail > at runtime; applications must use sysconf() to determine if it is actually Alternately, they can say "Screw you, OS designer!" and use it as if it were "-1", so that they don't have to add all sorts of runtime garbage to their programs, with multiple alternate code paths, etc.. Makes for much more readable code. > _POSIX_REALTIME_SIGNALS is undefined: > Apparently the same as when it is defined to 0, except you cannot assume > that anything related to it works until you call sysconf(), so you must > not reference its interfaces statically, and must use a dll or something > that references it. The dll is presumably available on systems that > support it but not (except possibly a dummy version) on systems that > don't support it. > > I think the case where the symbol is undefined should never be implemented > in practice. It can be reduced to the case where the symbol is 0 using > dynamic linkage with the complications for linkage not visible to the > application. I think you will have to go back in time, for this to happen. As things stand today, there are systems where it's undefined that were implemented before the symbol was a twinkle in some feature-test weenie on the POSIX committee's eye. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Oct 11 1:34:54 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 229DC37B401; Fri, 11 Oct 2002 01:34:52 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF3843E65; Fri, 11 Oct 2002 01:34:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA10239; Fri, 11 Oct 2002 18:34:42 +1000 Date: Fri, 11 Oct 2002 18:44:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Craig Rodrigues , , Subject: Re: Problem detecting POSIX symbolic constants In-Reply-To: <3DA5D5BD.1DAFF031@mindspring.com> Message-ID: <20021011183032.D12170-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 10 Oct 2002, Terry Lambert wrote: > Bruce Evans wrote: > > In Standard C, this is equivalent to the non-verbose version: > > > > #if _POSIX_REALTIME_SIGNALS != -1 > > ... > > #endif > > > > since if _POSIX_REALTIME_SIGNALS is not defined then it is equivalent to > > 0 in cpp expressions. The problem cases are if _POSIX_REALTIME_SIGNALS > > is defined to or , but these are not permitted in > > POSIX.1-2001. These cases were permitted for many feature test macros > > in POSIX.1-1990. > > I know it's not fashionable to write code that's portable to > compilers other than GCC, but even if FreeBSD is going to ignore > portability for it's own source code, it's probably unreasonable > to expect ACE to ignore portability for theirs. Undefined symbols being 0 in cpp in expressions was in early C compilers if not the original one. Consult your archives for a posting 10-15 years or so ago by dmr in comp.std.c about him checking this in his archives. > > > Sigh. Why did the POSIX guys do this? :( > > > > Perhaps because they wanted you to use sysconf() instead of these mistakes. > > Actually, they didn't do this. _POSIX_REALTIME_SIGNALS is specified to > > have value 0, -1 or 200xxxL (draft 7 says xxx; I think the final standard > > says 112). > > This can't be the case; specifically, the sysconf() test will > only work at runtime, which means that the symbols had to be > there and resolvable at link time. Symbols can be resolved at runtime using dlopen(), etc. They would only actually be available on systems where sysconf() says that they are. > > > BTW, I think that: > > > #if defined(_POSIX_REALTIME_SIGNALS) && (_POSIX_REALTIME_SIGNALS != -1 ) > > > > > > should suffice, but I'll double-check with one of my portability gurus > > > to see if that is OK for ACE. > > > > This is variant of the above verbose version. It requires slightly more > > modern compilers, so it might fail for some 20-year old pre-Standard C > > compilers instead of only for some 25-year old ones. > > Uh, the 1990 standard, which allowed "#if" is only 12 years old. #if is in K&R1 (1978). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Oct 11 1:43:33 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 921CD37B401; Fri, 11 Oct 2002 01:43:32 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DE1343EB3; Fri, 11 Oct 2002 01:43:31 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA11085; Fri, 11 Oct 2002 18:43:23 +1000 Date: Fri, 11 Oct 2002 18:53:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Craig Rodrigues , , Subject: Re: Problem detecting POSIX symbolic constants In-Reply-To: <3DA5D741.FB59AE1B@mindspring.com> Message-ID: <20021011184643.U12170-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 10 Oct 2002, Terry Lambert wrote: > Bruce Evans wrote: > > _POSIX_REALTIME_SIGNALS is undefined: > > Apparently the same as when it is defined to 0, except you cannot assume > > that anything related to it works until you call sysconf(), so you must > > not reference its interfaces statically, and must use a dll or something > > that references it. The dll is presumably available on systems that > > support it but not (except possibly a dummy version) on systems that > > don't support it. > > > > I think the case where the symbol is undefined should never be implemented > > in practice. It can be reduced to the case where the symbol is 0 using > > dynamic linkage with the complications for linkage not visible to the > > application. > > I think you will have to go back in time, for this to happen. As > things stand today, there are systems where it's undefined that > were implemented before the symbol was a twinkle in some feature-test > weenie on the POSIX committee's eye. _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. 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Oct 11 4: 2: 0 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 95CD037B401; Fri, 11 Oct 2002 04:01:59 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 750F143EB1; Fri, 11 Oct 2002 04:01:58 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA26228; Fri, 11 Oct 2002 21:01:48 +1000 Date: Fri, 11 Oct 2002 21:12:00 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Craig Rodrigues Cc: freebsd-standards@FreeBSD.ORG, Subject: Re: Problem detecting POSIX symbolic constants In-Reply-To: <20021010105531.A12354@attbi.com> Message-ID: <20021011210139.H12589-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 10 Oct 2002, Craig Rodrigues wrote: > On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote: > > Perhaps because they wanted you to use sysconf() instead of these mistakes. > > Well in the case of ACE, it is a C++ library that is compiled on > platforms which may or may not have sysconf() (ie. Windows), so using sysconf() is > not practical in this case. Checking a feature macro is much easier. How can new POSIX interfaces and new POSIX feature test macros work on systems that don't have ancient POSIX interfaces like sysconf(). As may have been clarified in other meesages in this thread, you need a new version of POSIX even to interpret _POSIX_REALTIME_SIGNALS. It is in POSIX.1-1996 and perhaps in earlier versions of POSIX (not including at least the 1990 one), so it is meaningless unless _POSIX_VERSION > 199mumble. > > I used a variant your patch for this in PR 35924 until recently when > > ... > This patch works for me. I think it is just as easy to just remove cruft from > the header file entirely, but since your patch effectively does the same > thing and has informative comments, that is fine. I slightly prefer to ifdef them, since an implementation is planned. > If your patch (or some equivalent variant) is committed, then I think > PR 35924 can be closed. Something needs to be done about these prototypes. OK, I will clean up the patch and commit it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Oct 11 12:47: 2 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 9BADF37B401; Fri, 11 Oct 2002 12:46:59 -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 3511843E8A; Fri, 11 Oct 2002 12:46:59 -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 1805k7-0007DY-00; Fri, 11 Oct 2002 12:46:39 -0700 Message-ID: <3DA72A53.9D2D61E5@mindspring.com> Date: Fri, 11 Oct 2002 12:45:23 -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: <20021011183032.D12170-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: > > I know it's not fashionable to write code that's portable to > > compilers other than GCC, but even if FreeBSD is going to ignore > > portability for it's own source code, it's probably unreasonable > > to expect ACE to ignore portability for theirs. > > Undefined symbols being 0 in cpp in expressions was in early C compilers > if not the original one. Consult your archives for a posting 10-15 years > or so ago by dmr in comp.std.c about him checking this in his archives. You mean "in preprocessor expressions", of course. > > This can't be the case; specifically, the sysconf() test will > > only work at runtime, which means that the symbols had to be > > there and resolvable at link time. > > Symbols can be resolved at runtime using dlopen(), etc. They would only > actually be available on systems where sysconf() says that they are. You can't depend on people using the standard C library via dlopen, as opposed to, uh, "linking". If you are depending on this, then you don't need sysconf: if the symbol isn't in the library, that's an equally valid indicator, so if the symbol lookup fail on a library open on Windows, which does not have sysconf at all (for example), it would have to be treated as equivalent. In UNIX, the symbol would have to be there, because the preferred linking technology *says* it has to be there for the link to succeed, if the symbol is referenced. Again, it's a *lot* easier for the programmers to say "screw this!", and blow off the runtime code morphing. > > Uh, the 1990 standard, which allowed "#if" is only 12 years old. > > #if is in K&R1 (1978). According to my first edition "The C Programming Language": 12.3 Conditional compilation A compiler control line of the form #if constant-expression checks whether the constant expression (see section 15) evaluates to non-zero. ... 15 Constant expressions In several places C requires expressions which evaluate to a constant: after case, as array bounds, and in initializers. In the first two cases, the expression can involve only integer constants, character constants, and sizeof expressions, possibly connected by the binary operators + - * / % & | ^ << >> == != < > <= >= or by the unary operators - ~ or by the ternary operator ?: ...no "&&" or "||"... sorry. Also, "defined()" is not defined. I think you will find that "&&" and "||" in #if statements are later extensions. The value of undefined macros in preprocessor expressions being assumed to be zero is also not documented in the book. I would have to imagine that they were not considered constant expressions. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message 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 From owner-freebsd-standards Sat Oct 12 0:39:26 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 5B66537B401; Sat, 12 Oct 2002 00:39:18 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42DAC43E8A; Sat, 12 Oct 2002 00:39:17 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA07511; Sat, 12 Oct 2002 17:39:09 +1000 Date: Sat, 12 Oct 2002 17:49:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: Craig Rodrigues , , Subject: Re: Problem detecting POSIX symbolic constants In-Reply-To: <3DA72A53.9D2D61E5@mindspring.com> Message-ID: <20021012171803.F15910-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 11 Oct 2002, Terry Lambert wrote: > Bruce Evans wrote: > > > I know it's not fashionable to write code that's portable to > > > compilers other than GCC, but even if FreeBSD is going to ignore > > > portability for it's own source code, it's probably unreasonable > > > to expect ACE to ignore portability for theirs. > > > > Undefined symbols being 0 in cpp in expressions was in early C compilers > > if not the original one. Consult your archives for a posting 10-15 years > > or so ago by dmr in comp.std.c about him checking this in his archives. > > You mean "in preprocessor expressions", of course. Oop. I meant only one "in" in "being 0 in cpp in [sic] expressions". > > > This can't be the case; specifically, the sysconf() test will > > > only work at runtime, which means that the symbols had to be > > > there and resolvable at link time. > > > > Symbols can be resolved at runtime using dlopen(), etc. They would only > > actually be available on systems where sysconf() says that they are. > > You can't depend on people using the standard C library via dlopen, > as opposed to, uh, "linking". Yes, a more careful reading of POSIX shows that if _POSIX_REALTIME_SIGNAL_ is undefined, then the (compile-time) system makes no claims as to the feature being either supported or unsupported. (Systems should leave it undefined it they are clueless about it.) The feature may still work at runtime, but the compile-time system makes no claims that it will or won't. Applications would have to do something magic to use it at runtime if it turns out to be present at runtime. It could easily be present at runtime because you update the OS. > > > Uh, the 1990 standard, which allowed "#if" is only 12 years old. > > > > #if is in K&R1 (1978). > > According to my first edition "The C Programming Language": > > 12.3 Conditional compilation > A compiler control line of the form > > #if constant-expression > > checks whether the constant expression (see section 15) > evaluates to non-zero. > > ... > > 15 Constant expressions > In several places C requires expressions which evaluate > to a constant: after case, as array bounds, and in initializers. > In the first two cases, the expression can involve only integer > constants, character constants, and sizeof expressions, possibly > connected by the binary operators > > + - * / % & | ^ << >> == != < > <= >= > > or by the unary operators > > - ~ > > or by the ternary operator > > ?: > > ...no "&&" or "||"... sorry. Also, "defined()" is not defined. > > I think you will find that "&&" and "||" in #if statements are > later extensions. > > The value of undefined macros in preprocessor expressions being > assumed to be zero is also not documented in the book. I would > have to imagine that they were not considered constant expressions. This book has lots of bugs (mostly from being too informal and/or omitting necessary details). Note that section 15 doesn't even mention "&&" and "||" working in non-cpp constant expressions. But they cetainly worked in expressions, and expressions with only constants in them are (informally) constant expessions. I think you are right that defined() didn't exist then. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Oct 12 1:47:30 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 25DC337B401; Sat, 12 Oct 2002 01:47:29 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB8D743EA3; Sat, 12 Oct 2002 01:47:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0112.cvx22-bradley.dialup.earthlink.net ([209.179.198.112] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 180Hva-0006a1-00; Sat, 12 Oct 2002 01:47:18 -0700 Message-ID: <3DA7E0F4.5988CA77@mindspring.com> Date: Sat, 12 Oct 2002 01:44:36 -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: <20021012171803.F15910-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: > This book has lots of bugs (mostly from being too informal and/or > omitting necessary details). Note that section 15 doesn't even mention > "&&" and "||" working in non-cpp constant expressions. But they > cetainly worked in expressions, and expressions with only constants > in them are (informally) constant expessions. I think you are right > that defined() didn't exist then. McCarthy operators are strange. I think that there wasn't an expectation that there would be an evaluation indirection, though you could build one with multiple terenary "?:" expressions. I think the lack of "||" and "&&" mostly had to do with the fact that there was conditional evaluation of the RHS of the operator, based on the result of the LHS. With just an "&" or an "|", you actually need a much less complicated state machine to evaluate a constant expression. With the "||"/"&&", you almost have to do an edge associative operation, which implies a much more complex state machine for the preprocessor, I think. So my guess as to why it's now supported is that the cpp we use today is actually derived from the compiler code itself (and in many compilers, like MSVC++, it's integrated into the compiler completely, and only available seperately as an afterthought)... it being supported is more or less a side effect. In any case, ACE has to be a lot more protable than, say, "ls". Though I'd personally like "ls" to be portable enough that every UNIX just compiled up the FreeBSD version of its own (the best way to establish a standard -- see TCP), it's OK for FreeBSD specific code to be less portable than code ported to FreeBSD. ...now if we only knew what "_POSIX_VERSION > mumble" needed for "mumble"... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Oct 12 7:13:46 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 5C97A37B401; Sat, 12 Oct 2002 07:13:45 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.135.138.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 182E343E7B; Sat, 12 Oct 2002 07:13:44 -0700 (PDT) (envelope-from fanf@chiark.greenend.org.uk) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #1) id 180N1N-0007BV-00 (Debian); Sat, 12 Oct 2002 15:13:37 +0100 Date: Sat, 12 Oct 2002 15:13:36 +0100 From: Tony Finch To: Terry Lambert Cc: Bruce Evans , Craig Rodrigues , freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021012151336.A24868@chiark.greenend.org.uk> References: <20021012171803.F15910-100000@gamplex.bde.org> <3DA7E0F4.5988CA77@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DA7E0F4.5988CA77@mindspring.com>; from tlambert2@mindspring.com on Sat, Oct 12, 2002 at 01:44:36AM -0700 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 On Sat, Oct 12, 2002 at 01:44:36AM -0700, Terry Lambert wrote: > > I think the lack of "||" and "&&" mostly had to do with the fact > that there was conditional evaluation of the RHS of the operator, > based on the result of the LHS. > > With just an "&" or an "|", you actually need a much less complicated > state machine to evaluate a constant expression. With the "||"/"&&", > you almost have to do an edge associative operation, which implies a > much more complex state machine for the preprocessor, I think. No -- the short-circuiting behaviour of && and || only matters if you can have side-effects, which you can't in the preprocessor, so there is no need to implement it (unifdef doesn't). Tony. -- f.a.n.finch http://dotat.at/ THAMES DOVER: SOUTHEASTERLY VEERING NORTHWESTERLY 4 OR 5, OCCASIONALLY 6, BECOMING VARIABLE 3. RAIN OR SHOWERS. MODERATE OR GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Oct 12 9:35:25 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 C4B5D37B401 for ; Sat, 12 Oct 2002 09:35:24 -0700 (PDT) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74FA043E7B for ; Sat, 12 Oct 2002 09:35:24 -0700 (PDT) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id E11399C10; Sat, 12 Oct 2002 12:27:51 -0400 (EDT) Date: Sat, 12 Oct 2002 12:27:51 -0400 From: Mike Barcroft To: Craig Rodrigues Cc: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021012122751.F78724@espresso.q9media.com> References: <20021006214520.B97120@espresso.q9media.com> <20021007232038.A13773@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021007232038.A13773@attbi.com>; from rodrigc@attbi.com on Mon, Oct 07, 2002 at 11:20:38PM -0400 Organization: The FreeBSD Project 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 Craig Rodrigues writes: > Hi, > > Here is my patch. __restrict was already added to sigwait() > in the .c file and man page, but not in the header file. Great. I think only change I made to the committed version was `*restrict' -> `* restrict' in the man pages (in keeping with the style for const type-qualifiers). How would you like to do next? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Oct 12 9:52:57 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 9D34537B401 for ; Sat, 12 Oct 2002 09:52:55 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8CCB43EA3 for ; Sat, 12 Oct 2002 09:52:54 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9CGrdCK023258 for ; Sat, 12 Oct 2002 12:53:39 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9CGrc7j023257 for freebsd-standards@freebsd.org; Sat, 12 Oct 2002 12:53:38 -0400 (EDT) Date: Sat, 12 Oct 2002 12:53:38 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021012125338.A23194@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> <20021007232038.A13773@attbi.com> <20021012122751.F78724@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021012122751.F78724@espresso.q9media.com>; from mike@FreeBSD.org on Sat, Oct 12, 2002 at 12:27:51PM -0400 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 On Sat, Oct 12, 2002 at 12:27:51PM -0400, Mike Barcroft wrote: > Great. I think only change I made to the committed version was > `*restrict' -> `* restrict' in the man pages (in keeping with the > style for const type-qualifiers). Cool. > How would you like to do next? OK, I'll look at it. By the way, can I ask a few things of you. (1) Would it be possible on the C99 and POSIX conformance web page to add some sections for: - POSIX message queues (mq_open(), mq_close(), etc.) - POSIX realtime signals (sigqueue(), sigtimedwait(), sigwaitinfo()) and label them as 0% complete? (I'm not volunteering to implement them just yet :). This web page gives a very good indicator of where FreeBSD stands with respect to conformance, and where it needs to go. (2) I'm not sure if this falls within the jurisdiction of the POSIX conformance project, but could you look at the patch I submitted to freebsd-current@freebsd.org and tell me if it is acceptable: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1705964+0+current/freebsd-current Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Oct 12 13:21:31 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 4103937B401; Sat, 12 Oct 2002 13:21:30 -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 D393743EAC; Sat, 12 Oct 2002 13:21:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0083.cvx21-bradley.dialup.earthlink.net ([209.179.192.83] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 180Sl8-0000KU-00; Sat, 12 Oct 2002 13:21:15 -0700 Message-ID: <3DA883F2.33E84C@mindspring.com> Date: Sat, 12 Oct 2002 13:20:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Finch Cc: Bruce Evans , Craig Rodrigues , freebsd-standards@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Problem detecting POSIX symbolic constants References: <20021012171803.F15910-100000@gamplex.bde.org> <3DA7E0F4.5988CA77@mindspring.com> <20021012151336.A24868@chiark.greenend.org.uk> 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 Tony Finch wrote: > > With just an "&" or an "|", you actually need a much less complicated > > state machine to evaluate a constant expression. With the "||"/"&&", > > you almost have to do an edge associative operation, which implies a > > much more complex state machine for the preprocessor, I think. > > No -- the short-circuiting behaviour of && and || only matters if > you can have side-effects, which you can't in the preprocessor, > so there is no need to implement it (unifdef doesn't). Consider: #if _DEFINED_SUPPORTED && defined(SOMETHING) -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Oct 12 20:18:18 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 DDE5637B401 for ; Sat, 12 Oct 2002 20:18:15 -0700 (PDT) Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 301B643EAC for ; Sat, 12 Oct 2002 20:18:15 -0700 (PDT) (envelope-from rodrigc@attbi.com) Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1]) by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9D3IxCK025232 for ; Sat, 12 Oct 2002 23:19:00 -0400 (EDT) (envelope-from rodrigc@dibbler.ne.client2.attbi.com) Received: (from rodrigc@localhost) by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9D3It7g025231 for freebsd-standards@freebsd.org; Sat, 12 Oct 2002 23:18:55 -0400 (EDT) Date: Sat, 12 Oct 2002 23:18:55 -0400 From: Craig Rodrigues To: freebsd-standards@freebsd.org Subject: Re: restrict qualifier task Message-ID: <20021012231855.A25219@attbi.com> References: <20021006214520.B97120@espresso.q9media.com> <20021007232038.A13773@attbi.com> <20021012122751.F78724@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021012122751.F78724@espresso.q9media.com>; from mike@FreeBSD.org on Sat, Oct 12, 2002 at 12:27:51PM -0400 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 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Oct 12, 2002 at 12:27:51PM -0400, Mike Barcroft wrote: > How would you like to do next? OK, according to the standard at: http://www.opengroup.org/onlinepubs/007904975/ I could only find the following prototypes in which required restrict qualifiers: accept, getpeername, getsockname, getsockopt, recvfrom I modified the header file and the man pages. However, it looks like each of these functions is implemented as a system call. Is anything further required? I was not confident enough to modify anything in /usr/src/sys/kern/* Is anything further than the submitted changes required? -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@attbi.com --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-1.txt" --- sys/sys/socket.h.orig Sat Oct 12 21:47:34 2002 +++ sys/sys/socket.h Sat Oct 12 23:07:49 2002 @@ -445,15 +445,15 @@ #include __BEGIN_DECLS -int accept(int, struct sockaddr *, socklen_t *); +int accept(int, struct sockaddr *__restrict, socklen_t *__restrict); int bind(int, const struct sockaddr *, socklen_t); int connect(int, const struct sockaddr *, socklen_t); -int getpeername(int, struct sockaddr *, socklen_t *); -int getsockname(int, struct sockaddr *, socklen_t *); -int getsockopt(int, int, int, void *, socklen_t *); +int getpeername(int, struct sockaddr *__restrict, socklen_t *__restrict); +int getsockname(int, struct sockaddr *__restrict, socklen_t *__restrict); +int getsockopt(int, int, int, void *__restrict, socklen_t *__restrict); int listen(int, int); ssize_t recv(int, void *, size_t, int); -ssize_t recvfrom(int, void *, size_t, int, struct sockaddr *, socklen_t *); +ssize_t recvfrom(int, void *__restrict, size_t, int, struct sockaddr *__restrict, socklen_t *__restrict); ssize_t recvmsg(int, struct msghdr *, int); ssize_t send(int, const void *, size_t, int); ssize_t sendto(int, const void *, --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-2.txt" --- lib/libc/sys/accept.2.orig Sat Oct 12 22:11:06 2002 +++ lib/libc/sys/accept.2 Sat Oct 12 22:11:40 2002 @@ -44,7 +44,7 @@ .In sys/types.h .In sys/socket.h .Ft int -.Fn accept "int s" "struct sockaddr *addr" "socklen_t *addrlen" +.Fn accept "int s" "struct sockaddr *restrict addr" "socklen_t *restrict addrlen" .Sh DESCRIPTION The argument .Fa s --- lib/libc/sys/getpeername.2.orig Sat Oct 12 22:12:38 2002 +++ lib/libc/sys/getpeername.2 Sat Oct 12 22:13:23 2002 @@ -44,7 +44,7 @@ .In sys/types.h .In sys/socket.h .Ft int -.Fn getpeername "int s" "struct sockaddr *name" "socklen_t *namelen" +.Fn getpeername "int s" "struct sockaddr *restrict name" "socklen_t *restrict namelen" .Sh DESCRIPTION .Fn Getpeername returns the name of the peer connected to --- lib/libc/sys/getsockname.2.orig Sat Oct 12 22:49:34 2002 +++ lib/libc/sys/getsockname.2 Sat Oct 12 22:50:10 2002 @@ -44,7 +44,7 @@ .In sys/types.h .In sys/socket.h .Ft int -.Fn getsockname "int s" "struct sockaddr *name" "socklen_t *namelen" +.Fn getsockname "int s" "struct sockaddr *restrict name" "socklen_t *restrict namelen" .Sh DESCRIPTION .Fn Getsockname returns the current --- lib/libc/sys/getsockopt.2.orig Sat Oct 12 22:52:49 2002 +++ lib/libc/sys/getsockopt.2 Sat Oct 12 22:53:02 2002 @@ -45,7 +45,7 @@ .In sys/types.h .In sys/socket.h .Ft int -.Fn getsockopt "int s" "int level" "int optname" "void *optval" "socklen_t *optlen" +.Fn getsockopt "int s" "int level" "int optname" "void *restrict optval" "socklen_t *restrict optlen" .Ft int .Fn setsockopt "int s" "int level" "int optname" "const void *optval" "socklen_t optlen" .Sh DESCRIPTION --- lib/libc/sys/recv.2.orig Sat Oct 12 22:55:59 2002 +++ lib/libc/sys/recv.2 Sat Oct 12 22:56:33 2002 @@ -48,7 +48,7 @@ .Ft ssize_t .Fn recv "int s" "void *buf" "size_t len" "int flags" .Ft ssize_t -.Fn recvfrom "int s" "void *buf" "size_t len" "int flags" "struct sockaddr *from" "socklen_t *fromlen" +.Fn recvfrom "int s" "void *restrict buf" "size_t len" "int flags" "struct sockaddr *restrict from" "socklen_t *restrict fromlen" .Ft ssize_t .Fn recvmsg "int s" "struct msghdr *msg" "int flags" .Sh DESCRIPTION --jRHKVT23PllUwdXP-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message