From owner-freebsd-standards@FreeBSD.ORG Sun Sep 9 07:30:08 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D4F16A421 for ; Sun, 9 Sep 2007 07:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 791C013C45D for ; Sun, 9 Sep 2007 07:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l897U8kv014433 for ; Sun, 9 Sep 2007 07:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l897U8YH014432; Sun, 9 Sep 2007 07:30:08 GMT (envelope-from gnats) Resent-Date: Sun, 9 Sep 2007 07:30:08 GMT Resent-Message-Id: <200709090730.l897U8YH014432@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jukka Ukkonen Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 445E016A417 for ; Sun, 9 Sep 2007 07:27:06 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 38FC513C48D for ; Sun, 9 Sep 2007 07:27:06 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l897R5ur044888 for ; Sun, 9 Sep 2007 07:27:05 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l897R5n9044887; Sun, 9 Sep 2007 07:27:05 GMT (envelope-from nobody) Message-Id: <200709090727.l897R5n9044887@www.freebsd.org> Date: Sun, 9 Sep 2007 07:27:05 GMT From: Jukka Ukkonen To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/116221: SUS issue -- FreeBSD has not flag WNOWAIT for wait*() calls X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 07:30:08 -0000 >Number: 116221 >Category: standards >Synopsis: SUS issue -- FreeBSD has not flag WNOWAIT for wait*() calls >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 09 07:30:07 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Jukka Ukkonen >Release: 6.2-STABLE >Organization: --- >Environment: FreeBSD mjolnir 6.2-STABLE FreeBSD 6.2-STABLE #0: Sun Sep 2 12:24:49 EET DST 2007 root@mjolnir:/usr/obj/usr/src/sys/Mjolnir i386 >Description: Notice! This is a complete rewrite of kern/109946 which was initially and in error categorized as a kern issue. Obviously this is much more a standards or compatibility issue. FreeBSD (and other BSDs) has had no WNOWAIT flag for the wait*() functions to tell the kernel not to remove the proc structure from which the exit status is returned. Sometimes one has only a limited set of functions which are aware of a certain child process. In threaded programs this is even more probable than when using traditional single threaded programs. To avoid a situation in which parts of a program removing unknown proc structures before another part which expects to be able to call wait*() to collect such an exit status it is worthwhile to have a flag allowing the program to first peek inside the structure without deleting the zombie from the process table. One can always call e.g. waitpid() to remove exactly one known zombie when one finds out a known child process has terminated. If one OTOH finds a zombie the PID of which is unknown to the caller, one can always just give up waiting instead of calling waitpid() with the recently found unknown PID. Removing a zombie before the functions knowing of the existence of a "hidden" child have a chance to wait for it makes other parts within a program unable to confirm the fate of such a child process. WNOWAIT is a SUS issue anyhow, and e.g. Sun/Solaris has had support for it for quite a long time. This is very quick and simple to change to become more compatible with other UNIX style systems. >How-To-Repeat: Here are minimal tools to test whether WNOWAIT works on your system. #include #include #include #include #include #include #include #ifndef RUSAGE_SELF # define RUSAGE_SELF 0 #endif #ifndef RUSAGE_CHILDREN # define RUSAGE_CHILDREN -1 #endif int dump_rusage (file, rusage, header) FILE *file; struct rusage *rusage; const char *header; { if (! file || ! rusage) { errno = EFAULT; return (-1); } if (! header || ! *header) header = "Resource utilization:"; fprintf (file, "%s%s\n", header, ((header[strlen (header) - 1] == ':') ? "" : ":")); fprintf (file, "\tuser time:\t\t\t%lu.%.6lu\n", rusage->ru_utime.tv_sec, rusage->ru_utime.tv_usec); fprintf (file, "\tsystem time:\t\t\t%lu.%.6lu\n", rusage->ru_stime.tv_sec, rusage->ru_stime.tv_usec); fprintf (file, "\tmax resident set size:\t\t%ld\n", rusage->ru_maxrss); fprintf (file, "\tshared text memory size:\t%ld\n", rusage->ru_ixrss); fprintf (file, "\tunshared data size:\t\t%ld\n", rusage->ru_idrss); fprintf (file, "\tunshared stack size:\t\t%ld\n", rusage->ru_isrss); fprintf (file, "\tpage reclaims:\t\t\t%ld\n", rusage->ru_minflt); fprintf (file, "\tpage faults:\t\t\t%ld\n", rusage->ru_majflt); fprintf (file, "\tswaps:\t\t\t\t%ld\n", rusage->ru_nswap); fprintf (file, "\tblock input operations:\t\t%ld\n", rusage->ru_inblock); fprintf (file, "\tblock output operations:\t%ld\n", rusage->ru_oublock); fprintf (file, "\tmessages sent:\t\t\t%ld\n", rusage->ru_msgsnd); fprintf (file, "\tmessages received:\t\t%ld\n", rusage->ru_msgrcv); fprintf (file, "\tsignals received:\t\t%ld\n", rusage->ru_nsignals); fprintf (file, "\tvoluntary context switches:\t%ld\n", rusage->ru_nvcsw); fprintf (file, "\tinvoluntary context switches:\t%ld\n", rusage->ru_nivcsw); return (0); } #ifndef WNOWAIT # warning WNOWAIT undefined and will be defined as 0. # define WNOWAIT 0 #endif int main (ac, av) int ac; char *av[]; { pid_t child; pid_t pid; int status; struct rusage res; child = fork (); if (child < 0) { perror ("fork()"); exit (-1); } if (! child) { _exit (0); } pid = wait4 (-1, &status, WNOWAIT, &res); if (pid < 0) { perror ("wait4()"); pid = -1; } if (pid != child) { fprintf (stderr, "wait4(): pid != child\n"); } printf ("PID = %d ...\n", (int) pid); dump_rusage (stdout, &res, NULL); pid = wait4 (child, &status, 0, &res); if (pid < 0) { perror ("wait4()"); } else { printf ("PID = %d ...\n", (int) pid); dump_rusage (stdout, &res, NULL); } pid = wait4 (child, &status, 0, &res); if (pid < 0) { perror ("wait4()"); } else { printf ("PID = %d ...\n", (int) pid); dump_rusage (stdout, &res, NULL); } return (0); } >Fix: Apply the attached patch. I have been running 6-STABLE with this modification since early 2007 with no ill effects at all. Patch attached with submission follows: --- /usr/src/sys/sys/wait.h.orig 2005-01-06 00:19:44.000000000 +0200 +++ /usr/src/sys/sys/wait.h 2007-09-09 05:32:34.000000000 +0300 @@ -78,7 +78,9 @@ */ #define WNOHANG 1 /* Don't hang in wait. */ #define WUNTRACED 2 /* Tell about stopped, untraced children. */ +#define WSTOPPED WUNTRACED /* SUS compatibility */ #define WCONTINUED 4 /* Report a job control continued process. */ +#define WNOWAIT 8 /* Poll only. Don't delete the proc entry. */ #if __BSD_VISIBLE #define WLINUXCLONE 0x80000000 /* Wait for kthread spawned from linux_clone. */ --- /usr/src/sys/kern/kern_exit.c.orig 2007-05-17 16:52:37.000000000 +0300 +++ /usr/src/sys/kern/kern_exit.c 2007-09-09 05:32:34.000000000 +0300 @@ -584,7 +584,7 @@ pid = -q->p_pgid; PROC_UNLOCK(q); } - if (options &~ (WUNTRACED|WNOHANG|WCONTINUED|WLINUXCLONE)) + if (options &~ (WUNTRACED|WNOHANG|WCONTINUED|WNOWAIT|WLINUXCLONE)) return (EINVAL); loop: if (q->p_flag & P_STATCHILD) { @@ -644,11 +644,32 @@ calcru(p, &rusage->ru_utime, &rusage->ru_stime); } + PROC_UNLOCK(p); + + if (options & WNOWAIT) { + /* + * SUS compatibility. + * + * We poll only returning the status. + * We do not wish to release the proc + * struct just yet. + * ==> If another thread created this + * process, it is sometimes better to + * leave this one as is for now and let + * the other thread reap the remnants + * of the child instead of automatically + * destroying the proc entry and making + * it impossible for the other thread to + * wait for its own child process. + */ + sx_xunlock(&proctree_lock); + return (0); + } + /* * If we got the child via a ptrace 'attach', * we need to give it back to the old parent. */ - PROC_UNLOCK(p); if (p->p_oppid && (t = pfind(p->p_oppid)) != NULL) { PROC_LOCK(p); p->p_oppid = 0; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Mon Sep 10 11:08:23 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC75716A4EE for ; Mon, 10 Sep 2007 11:08:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD9913C47E for ; Mon, 10 Sep 2007 11:08:23 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8AB8NOD017412 for ; Mon, 10 Sep 2007 11:08:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8AB8MRw017408 for freebsd-standards@FreeBSD.org; Mon, 10 Sep 2007 11:08:22 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Sep 2007 11:08:22 GMT Message-Id: <200709101108.l8AB8MRw017408@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:08:23 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards /bin/sh: null char in quoted string o kern/46239 standards posix semaphore implementation errors o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o stand/114910 standards getaddrinfo() fails to set ai_canonname 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec s kern/28260 standards UIO_MAXIOV needs to be made public s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [feature request] add a system call: fd o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards _gettemp uses a far smaller set of filenames than docu o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/85080 standards output of long double subnormals (with printf) is wron o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/104841 standards [libm] [patch] C99 long double square root. o stand/107561 standards [patch] Missing SUS function tcgetsid() o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/114633 standards /etc/rc.subr: line 511: omits a quotation mark: "force o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards SUS issue -- FreeBSD has not flag WNOWAIT for wait*() 40 problems total. From owner-freebsd-standards@FreeBSD.ORG Fri Sep 14 12:00:06 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBD1916A4A9 for ; Fri, 14 Sep 2007 12:00:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 33F3E13C4A6 for ; Fri, 14 Sep 2007 12:00:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8EC06qd080618 for ; Fri, 14 Sep 2007 12:00:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8EC057i080617; Fri, 14 Sep 2007 12:00:05 GMT (envelope-from gnats) Resent-Date: Fri, 14 Sep 2007 12:00:05 GMT Resent-Message-Id: <200709141200.l8EC057i080617@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Olaf Seibert Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFADC16A419 for ; Fri, 14 Sep 2007 11:50:12 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id E013813C458 for ; Fri, 14 Sep 2007 11:50:12 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.1/8.14.1) with ESMTP id l8EBoCE9068422 for ; Fri, 14 Sep 2007 11:50:12 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.1/8.14.1/Submit) id l8EBoC1s068421; Fri, 14 Sep 2007 11:50:12 GMT (envelope-from nobody) Message-Id: <200709141150.l8EBoC1s068421@www.freebsd.org> Date: Fri, 14 Sep 2007 11:50:12 GMT From: Olaf Seibert To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/116346: FreeBSD has no conforming C implementation X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 12:00:07 -0000 >Number: 116346 >Category: standards >Synopsis: FreeBSD has no conforming C implementation >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Sep 14 12:00:05 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Olaf Seibert >Release: 6.1 >Organization: >Environment: FreeBSD twoquid.cs.ru.nl 6.1-RELEASE FreeBSD 6.1-RELEASE #2: Mon Mar 19 15:05:26 CET 2007 root@twoquid.cs.ru.nl:/usr/src/sys/amd64/compile/TWOQUID amd64 >Description: The following strictly conforming little C program fails to compile on FreeBSD 6.1 (and I've had the same report about FreeBSD 7). int main(int argc, char **argv) { int unix = 2; return 0; } $ uname -a FreeBSD twoquid.cs.ru.nl 6.1-RELEASE FreeBSD 6.1-RELEASE #2: Mon Mar 19 15:05:26 CET 2007 root@twoquid.cs.ru.nl:/usr/src/sys/amd64/compile/TWOQUID amd64 $ gcc c.c c.c: In function `main': c.c:3: error: syntax error before numeric constant The problem is the pre-definition of the preprocessor symbol "unix". The C standard does not allow that. Reference: ISO/IEC 9899:TC2 section 7.1.3 "Reserved Identifiers". Para 1 lists the identifiers the compiler may predefine ("reserve"). Para 2: "No other identifiers are reserved". http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf Section 4 "Conformance" para 6 says (implies) that a conforming implementation (of C) reserves no identifiers other than those explictly reserved in the C standard. Therefore, FreeBSD has no conforming C implementation. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse. >How-To-Repeat: compile the above program. >Fix: Remove the predefine in the gcc build. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Fri Sep 14 13:10:07 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5702716A418 for ; Fri, 14 Sep 2007 13:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3813413C459 for ; Fri, 14 Sep 2007 13:10:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8EDA62A086532 for ; Fri, 14 Sep 2007 13:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8EDA66Z086531; Fri, 14 Sep 2007 13:10:06 GMT (envelope-from gnats) Date: Fri, 14 Sep 2007 13:10:06 GMT Message-Id: <200709141310.l8EDA66Z086531@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Erik Trulsson Cc: Subject: Re: standards/116346: FreeBSD has no conforming C implementation X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Erik Trulsson List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 13:10:07 -0000 The following reply was made to PR standards/116346; it has been noted by GNATS. From: Erik Trulsson To: Olaf Seibert Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: standards/116346: FreeBSD has no conforming C implementation Date: Fri, 14 Sep 2007 14:44:50 +0200 On Fri, Sep 14, 2007 at 11:50:12AM +0000, Olaf Seibert wrote: > > >Number: 116346 > >Category: standards > >Synopsis: FreeBSD has no conforming C implementation > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-standards > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Fri Sep 14 12:00:05 GMT 2007 > >Closed-Date: > >Last-Modified: > >Originator: Olaf Seibert > >Release: 6.1 > >Organization: > >Environment: > FreeBSD twoquid.cs.ru.nl 6.1-RELEASE FreeBSD 6.1-RELEASE #2: Mon Mar 19 15:05:26 CET 2007 root@twoquid.cs.ru.nl:/usr/src/sys/amd64/compile/TWOQUID amd64 > >Description: > The following strictly conforming little C program fails to compile on > FreeBSD 6.1 (and I've had the same report about FreeBSD 7). > > int main(int argc, char **argv) > { > int unix = 2; > return 0; > } > > $ uname -a > FreeBSD twoquid.cs.ru.nl 6.1-RELEASE FreeBSD 6.1-RELEASE #2: Mon Mar 19 15:05:26 CET 2007 root@twoquid.cs.ru.nl:/usr/src/sys/amd64/compile/TWOQUID amd64 > $ gcc c.c > c.c: In function `main': > c.c:3: error: syntax error before numeric constant > > The problem is the pre-definition of the preprocessor symbol "unix". The > C standard does not allow that. > > Reference: ISO/IEC 9899:TC2 section 7.1.3 "Reserved Identifiers". > Para 1 lists the identifiers the compiler may predefine ("reserve"). > Para 2: "No other identifiers are reserved". > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf > > Section 4 "Conformance" para 6 says (implies) that a conforming > implementation (of C) reserves no identifiers other than those explictly > reserved in the C standard. > > Therefore, FreeBSD has no conforming C implementation. Yes, it does. You do however have to invoke the C compiler in standard-conforming mode. By default gcc (like most C compilers) is not in standards-conforming mode. Try invoking it as 'gcc -ansi' or 'c89' to get a C compiler conforming to the 1989 ANSI C standard. (Invoking it as 'c99' or as 'gcc -std=c99' should get a C99 compiler, although I believe support for the 1999 C standard is not quite complete.) This is all documented quite clearly in the manpages for c89(1), c99(1) and gcc(1). -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Fri Sep 14 13:40:06 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C88EB16A41A for ; Fri, 14 Sep 2007 13:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3AA113C461 for ; Fri, 14 Sep 2007 13:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8EDe6fV089884 for ; Fri, 14 Sep 2007 13:40:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8EDe6BN089882; Fri, 14 Sep 2007 13:40:06 GMT (envelope-from gnats) Date: Fri, 14 Sep 2007 13:40:06 GMT Message-Id: <200709141340.l8EDe6BN089882@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Rhialto Cc: Subject: Re: standards/116346: FreeBSD has no conforming C implementation X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rhialto List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 13:40:06 -0000 The following reply was made to PR standards/116346; it has been noted by GNATS. From: Rhialto To: Erik Trulsson Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: standards/116346: FreeBSD has no conforming C implementation Date: Fri, 14 Sep 2007 15:35:06 +0200 On Fri 14 Sep 2007 at 14:44:50 +0200, Erik Trulsson wrote: > Yes, it does. You do however have to invoke the C compiler in > standard-conforming mode. > By default gcc (like most C compilers) is not in standards-conforming mode. > > Try invoking it as 'gcc -ansi' or 'c89' to get a C compiler conforming to > the 1989 ANSI C standard. (Invoking it as 'c99' or as 'gcc -std=c99' should > get a C99 compiler, although I believe support for the 1999 C standard is > not quite complete.) Of course no makefile project ever does that at all, in practice, yet they still expect to have the promised namespace available for their own identifiers. I was made aware of this problem when some project was using the "unix" preprocessor definition as a feature test, and it failed to build on a different BSD system, which IMHO is more correct in this regard. I don't know where to look this up in POSIX and related standards, but I don't expect that any of them actually *requires* a pre-#defined unix, since they most likely don't want to contradict the C standard. If they would mention any such feature test at all, they would require #inclusion of some specific header first, or use a name which is reserved to the implementation, such as __unix__. Otherwise, by your reasoning, the default-invoked compiler could do anything, and you would not need to bother having all those __-prefixed names in /usr/include/sys/*. Therefore, there is no standards-related reason for having "unix" and I still argue for removing it. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse. From owner-freebsd-standards@FreeBSD.ORG Fri Sep 14 14:57:51 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C738816A417 for ; Fri, 14 Sep 2007 14:57:51 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7912013C459 for ; Fri, 14 Sep 2007 14:57:51 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 16:44:35 +0200 Date: Fri, 14 Sep 2007 16:44:35 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Rhialto In-Reply-To: <200709141340.l8EDe6BN089882@freefall.freebsd.org> Message-ID: <20070914163307.F92964@knop-beagle.kn.op.dlr.de> References: <200709141340.l8EDe6BN089882@freefall.freebsd.org> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 14 Sep 2007 14:44:35.0383 (UTC) FILETIME=[C4D4BC70:01C7F6DD] Cc: freebsd-standards@FreeBSD.org Subject: Re: standards/116346: FreeBSD has no conforming C implementation X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 14:57:51 -0000 On Fri, 14 Sep 2007, Rhialto wrote: R>The following reply was made to PR standards/116346; it has been noted by GNATS. R> R>From: Rhialto R>To: Erik Trulsson R>Cc: freebsd-gnats-submit@FreeBSD.org R>Subject: Re: standards/116346: FreeBSD has no conforming C implementation R>Date: Fri, 14 Sep 2007 15:35:06 +0200 R> R> On Fri 14 Sep 2007 at 14:44:50 +0200, Erik Trulsson wrote: R> > Yes, it does. You do however have to invoke the C compiler in R> > standard-conforming mode. R> > By default gcc (like most C compilers) is not in standards-conforming mode. R> > R> > Try invoking it as 'gcc -ansi' or 'c89' to get a C compiler conforming to R> > the 1989 ANSI C standard. (Invoking it as 'c99' or as 'gcc -std=c99' should R> > get a C99 compiler, although I believe support for the 1999 C standard is R> > not quite complete.) R> R> Of course no makefile project ever does that at all, in practice, yet R> they still expect to have the promised namespace available for their own R> identifiers. R> R> I was made aware of this problem when some project was using the "unix" R> preprocessor definition as a feature test, and it failed to build on a R> different BSD system, which IMHO is more correct in this regard. R> R> I don't know where to look this up in POSIX and related standards, but I R> don't expect that any of them actually *requires* a pre-#defined unix, R> since they most likely don't want to contradict the C standard. If they R> would mention any such feature test at all, they would require R> #inclusion of some specific header first, or use a name which is R> reserved to the implementation, such as __unix__. R> R> Otherwise, by your reasoning, the default-invoked compiler could do R> anything, and you would not need to bother having all those __-prefixed R> names in /usr/include/sys/*. R> R> Therefore, there is no standards-related reason for having "unix" and I R> still argue for removing it. If you look at posix you will see two things: - Posix reserves a lot of names that are not in the implementation name space. As an example everything ending in _t or beginning with str is reserved. So unix might be reserved, but actually isn't. - Posix defines the name of the C-compiler as c99. You invoked the compiler as gcc so it is no surprise that it does something different. - As far as I remember C99 does not define the name of the compiler, so, if you're on a posix system you should use c99, if you are on a non-posix system it should be defined by the system so you cannot actually expect the name gcc to call the c99 compiler. And yes, I understand you. I was several times hit by the Solaris compilers defining the identifier sun as 1. Argh. harti From owner-freebsd-standards@FreeBSD.ORG Fri Sep 14 15:00:11 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 841FC16A468 for ; Fri, 14 Sep 2007 15:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8173413C45E for ; Fri, 14 Sep 2007 15:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8EF0AGj093596 for ; Fri, 14 Sep 2007 15:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8EF0Al2093594; Fri, 14 Sep 2007 15:00:10 GMT (envelope-from gnats) Date: Fri, 14 Sep 2007 15:00:10 GMT Message-Id: <200709141500.l8EF0Al2093594@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Erik Trulsson Cc: Subject: Re: standards/116346: FreeBSD has no conforming C implementation X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Erik Trulsson List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 15:00:11 -0000 The following reply was made to PR standards/116346; it has been noted by GNATS. From: Erik Trulsson To: Rhialto Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: standards/116346: FreeBSD has no conforming C implementation Date: Fri, 14 Sep 2007 16:53:45 +0200 On Fri, Sep 14, 2007 at 03:35:06PM +0200, Rhialto wrote: > On Fri 14 Sep 2007 at 14:44:50 +0200, Erik Trulsson wrote: > > Yes, it does. You do however have to invoke the C compiler in > > standard-conforming mode. > > By default gcc (like most C compilers) is not in standards-conforming mode. > > > > Try invoking it as 'gcc -ansi' or 'c89' to get a C compiler conforming to > > the 1989 ANSI C standard. (Invoking it as 'c99' or as 'gcc -std=c99' should > > get a C99 compiler, although I believe support for the 1999 C standard is > > not quite complete.) > > Of course no makefile project ever does that at all, in practice, yet > they still expect to have the promised namespace available for their own > identifiers. They should not expect that. > > I was made aware of this problem when some project was using the "unix" > preprocessor definition as a feature test, and it failed to build on a > different BSD system, which IMHO is more correct in this regard. You mean the "correct" system is the one where this program did *not* compile? Perhaps correct, but not terribly useful IMNSHO. > > I don't know where to look this up in POSIX and related standards, but I > don't expect that any of them actually *requires* a pre-#defined unix, > since they most likely don't want to contradict the C standard. If they > would mention any such feature test at all, they would require > #inclusion of some specific header first, or use a name which is > reserved to the implementation, such as __unix__. > > Otherwise, by your reasoning, the default-invoked compiler could do > anything, and you would not need to bother having all those __-prefixed > names in /usr/include/sys/*. No relevant standard say anything at all about what should happen or not happen if you invoke a C compiler in non-conforming mode. > > Therefore, there is no standards-related reason for having "unix" and I > still argue for removing it. As far as I know no standard requires "unix" to be predefined. The reason it exists is presumably for compatibility with older programs and older compilers that did use it. For programs that require a standard-conforming compiler you can invoke the C compiler as described above. The fact that GCC by default is in non-standard comforming mode should come as a surprise to nobody. That has after all been the case for the last two decades and is quite well documented by now. It is worth noting that I as far as I can tell there is also no standard that requires 'cc' by itself to invoke a fully standard-compliant C compiler -- which C dialect it will compile is not specified. If you need a C compiler that is standard compliant you should use 'c89' (which has apparently been replaced by 'c99' in the latest POSIX standard.) As far as I can tell FreeBSD *does* have a conforming C compiler, and *is* complying with the relevant standards in this aspect. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-standards@FreeBSD.ORG Sat Sep 15 15:11:44 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2ABB16A41B; Sat, 15 Sep 2007 15:11:43 +0000 (UTC) (envelope-from rodrigc@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DA15A13C46E; Sat, 15 Sep 2007 15:11:43 +0000 (UTC) (envelope-from rodrigc@FreeBSD.org) Received: from freefall.freebsd.org (rodrigc@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8FFBhZO081616; Sat, 15 Sep 2007 15:11:43 GMT (envelope-from rodrigc@freefall.freebsd.org) Received: (from rodrigc@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8FFBhVk081612; Sat, 15 Sep 2007 15:11:43 GMT (envelope-from rodrigc) Date: Sat, 15 Sep 2007 15:11:43 GMT Message-Id: <200709151511.l8FFBhVk081612@freefall.freebsd.org> To: rhialto@falu.nl, rodrigc@FreeBSD.org, freebsd-standards@FreeBSD.org From: rodrigc@FreeBSD.org Cc: Subject: Re: standards/116346: FreeBSD has no conforming C implementation X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 15:11:44 -0000 Synopsis: FreeBSD has no conforming C implementation State-Changed-From-To: open->closed State-Changed-By: rodrigc State-Changed-When: Sat Sep 15 15:07:43 UTC 2007 State-Changed-Why: Invoking compiler as "c99" or using gcc -ansi will get the behavior. Refer to gcc documentation: http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/C-Dialect-Options.html http://www.freebsd.org/cgi/query-pr.cgi?pr=116346