From owner-freebsd-standards@FreeBSD.ORG Sun Feb 6 08:36:27 2011 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8439B106566B for ; Sun, 6 Feb 2011 08:36:27 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 167328FC16 for ; Sun, 6 Feb 2011 08:36:26 +0000 (UTC) Received: by wwf26 with SMTP id 26so3686315wwf.31 for ; Sun, 06 Feb 2011 00:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v74kmmFeZ3QD6k5kR3OxRTPi81TY9Ht9Eul4d5q4PnA=; b=wOy3npO9fmlzk9VJeyqB/Qq7gdK+B1OhSv1fV2MRr2dDxcjcu2RFZqfhb7sPjJe3Xh PBIRTzbIHiYfTp2/tHejJLgMYMJGRjoRb2YNjY9YEi8H77ORSHenQSs89zgJXVPAORro pnrKvi5KOF1o1OkN5JDsFkrHLn1GIAy8Cwt1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MGP23Ul224SXqipWEDL9TCTFka/evQjoyZk40fcXBVi1ofKy2hGaPBM4QAXtMWHP63 2QkTEYw7gpO0BfbVZoCk1rB9PnSR6KQa8cNQ/ukkeLzsUCtQN3bskQtS1zbL9l2ZC70R E5iSxpQzdz6po7A+hJnBkoROw1szkLlSpBRhk= MIME-Version: 1.0 Received: by 10.216.154.8 with SMTP id g8mr1096564wek.12.1296981385828; Sun, 06 Feb 2011 00:36:25 -0800 (PST) Received: by 10.216.71.200 with HTTP; Sun, 6 Feb 2011 00:36:25 -0800 (PST) In-Reply-To: <297240.61774.qm@web113506.mail.gq1.yahoo.com> References: <297240.61774.qm@web113506.mail.gq1.yahoo.com> Date: Sun, 6 Feb 2011 00:36:25 -0800 Message-ID: From: Garrett Cooper To: standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "Pedro F. Giffuni" Subject: Fwd: FreeBSD and Standards Wiki X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 08:36:27 -0000 Functionally I agree with you, but it should be in limits.h to be fully compliant with POSIX. Same with PTHREAD_STACK_MIN. I haven't looked at other areas beyond just those two constants. I'll add this discrepancy to the wiki. Thanks! -Garrett ---------- Forwarded message ---------- From: Pedro F. Giffuni Date: Fri, Feb 4, 2011 at 8:30 AM Subject: Re: FreeBSD and Standards Wiki To: Garrett Cooper Hi again Garrett; Just for fun (a strange definition of fun), I gave a try to update the devel/linuxthreads port and I found a minor compliance issue: PTHREAD_KEYS_MAX should be defined in limits.h according to this: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html we have it pthread.h (which actually makes sense). From owner-freebsd-standards@FreeBSD.ORG Sun Feb 6 20:04:32 2011 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 9DD11106564A for ; Sun, 6 Feb 2011 20:04:32 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6046D8FC08 for ; Sun, 6 Feb 2011 20:04:32 +0000 (UTC) Received: from p5796fb7b.dip.t-dialin.net ([87.150.251.123] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PmALP-00052r-1k; Sun, 06 Feb 2011 20:32:23 +0100 Message-ID: <4D4EF746.9070502@gwdg.de> Date: Sun, 06 Feb 2011 20:32:22 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.13) Gecko/20101218 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Murray Stokely Subject: Support for C99 complex type required X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2011 20:04:32 -0000 For more than a decade now it was possible to install the statistical program R (http://cran.r-project.org/) from the sources, even without patching. Since fortran was removed from the system, lang/gcc44 or lang/gcc45 has to be installed before. In addition a nice port exists for years now: math/R. With the new development version of R ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz the configure script stops complaining about missing C99 complex types. This is reproducable with only untaring the sources and starting configure script in R-devel with ./configure. There was a discussion on the R-devel mailing list about it. The developers came to the conclusion that there is no support for complex functions complied with C99 standard in FreeBSD. http://gcc.gnu.org/gcc-4.2/c99status.html As far as I can see (I am not a programmer) FreeBSD is using the old c99 wrapper file in /usr/bin. Am I right that lang/gcc45 should support such complex functions? http://gcc.gnu.org/gcc-4.5/c99status.html Is there any way to get access to C99 complex functions of gcc-4.5.3 or newer at least within a port? Thanks for any hint, Rainer Hurling From owner-freebsd-standards@FreeBSD.ORG Mon Feb 7 11:07:09 2011 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 AE2B2106564A for ; Mon, 7 Feb 2011 11:07:09 +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 9C7F08FC2A for ; Mon, 7 Feb 2011 11:07:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p17B79UB027872 for ; Mon, 7 Feb 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p17B79F7027870 for freebsd-standards@FreeBSD.org; Mon, 7 Feb 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Feb 2011 11:07:09 GMT Message-Id: <201102071107.p17B79F7027870@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 freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 11:07:09 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/154185 standards race condition in mb_dupcl o stand/153756 standards fp leak in hesiod.c . o stand/152415 standards [libm] implementation of expl() o stand/151316 standards lib/libc/string/strerror.c r1.9 breaks POSIX o stand/150093 standards C++ std::locale support is broken a stand/149980 standards [libc] [patch] negative value integer to nanosleep(2) o stand/147210 standards xmmintrin.h and cstdlib conflicts with each other with o stand/144231 standards bind/connect/sendto too strict about sockaddr length o stand/142803 standards j0 Bessel function inaccurate near zeros of the functi s stand/141705 standards [libc] [request] libc lacks cexp (and friends) o stand/130067 standards Wrong numeric limits in system headers? o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude o stand/114633 standards /etc/rc.subr: line 511: omits a quotation mark: "force p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards [patch] cd9660 unicode support simple hack o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 43 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Feb 7 19:37:40 2011 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 8F7A01065675 for ; Mon, 7 Feb 2011 19:37:40 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6B28FC15 for ; Mon, 7 Feb 2011 19:37:39 +0000 (UTC) Received: by yxh35 with SMTP id 35so1965581yxh.13 for ; Mon, 07 Feb 2011 11:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:cc:content-type; bh=IlVoKlmz6G+D/LARRNcThIOtQehPzvEdq75MpmdX9/E=; b=xVGU65VYXvQBDO4qWO0+hqecYz2wXnOxW1br8uso7wav+yAoN3Zrc/PmeLXaEqhR59 GNH/5xiS/cjToYraLK9oozpCurnnw+gKRYI2YXprae/ngMUQJ1/9E5o+lJOYOcqqIy0o mzxEq/0aFmpFXlb9WsMsKluwLQhDXsvkCNrqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=jqcf8kQ99cv78C+ed6LcQNpnKiMRrZKyctwMnYuyLKgG3UmundUOWp2ANBE8yZ+dDy pKOyF3ldG5jAbn/1mvH/6ho0pBB9HyHibDxpMvBO0vRPb+Q94RsOtaSZJQ9NUBPuU+O/ nLY6EMLLxpG1BdtB6JibiMRcLrYw+f4vG+FWk= MIME-Version: 1.0 Received: by 10.236.109.52 with SMTP id r40mr30537426yhg.52.1297105370976; Mon, 07 Feb 2011 11:02:50 -0800 (PST) Received: by 10.236.110.52 with HTTP; Mon, 7 Feb 2011 11:02:50 -0800 (PST) Date: Mon, 7 Feb 2011 14:02:50 -0500 Message-ID: From: "b. f." To: Rainer Hurling Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-standards@FreeBSD.org Subject: Re: Support for C99 complex type required X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 19:37:40 -0000 > For more than a decade now it was possible to install the statistical > program R (http://cran.r-project.org/) from the sources, even without > patching. Since fortran was removed from the system, lang/gcc44 or > lang/gcc45 has to be installed before. In addition a nice port exists > for years now: math/R. > > With the new development version of R > > ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz > > the configure script stops complaining about missing C99 complex types. > This is reproducable with only untaring the sources and starting > configure script in R-devel with ./configure. > > There was a discussion on the R-devel mailing list about it. The > developers came to the conclusion that there is no support for complex > functions complied with C99 standard in FreeBSD. > > http://gcc.gnu.org/gcc-4.2/c99status.html > > As far as I can see (I am not a programmer) FreeBSD is using the old c99 > wrapper file in /usr/bin. Am I right that lang/gcc45 should support such > complex functions? > > http://gcc.gnu.org/gcc-4.5/c99status.html > > Is there any way to get access to C99 complex functions of gcc-4.5.3 or > newer at least within a port? I am the math/R maintainer, and I do not subscribe to this list, although I occasionally read it. Therefore it would be better to ask me directly regarding questions about R, even if they are an appropriate, in a wider sense, for this list. Yes, you can use some of the C99 complex machinery, enough to satisfy R, which provides crude implementations of some of it if you have no support for it otherwise (in, e.g., src/main/complex.c). But you should use lang/gcc4* and the appropriate compiler flags -- if you are using /usr/bin/c99, you are using the wrong compiler suite. The port sets USE_FORTRAN=yes, which points R in the right direction. If you are not a programmer, why not just use the port? Or, if you really need the development version, why not use the port as a basis for your own locally-patched port? Generally speaking, you cannot expect to build software that is largely developed on other platforms without some modifications. In any event, I too would like to see better support in the base system for C99 math, which is being used by an increasing number of software packages. b. From owner-freebsd-standards@FreeBSD.ORG Mon Feb 7 20:30:02 2011 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 A6D231065693 for ; Mon, 7 Feb 2011 20:30:02 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 54F088FC0C for ; Mon, 7 Feb 2011 20:30:02 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p17K8drm082369; Mon, 7 Feb 2011 15:08:39 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p17K8dm3082368; Mon, 7 Feb 2011 15:08:39 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 7 Feb 2011 15:08:39 -0500 From: David Schultz To: Rainer Hurling Message-ID: <20110207200839.GA82306@zim.MIT.EDU> Mail-Followup-To: Rainer Hurling , freebsd-standards@freebsd.org, Murray Stokely References: <4D4EF746.9070502@gwdg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D4EF746.9070502@gwdg.de> Cc: Murray Stokely , freebsd-standards@FreeBSD.ORG Subject: Re: Support for C99 complex type required X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:30:02 -0000 On Sun, Feb 06, 2011, Rainer Hurling wrote: > With the new development version of R > > ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz > > the configure script stops complaining about missing C99 complex types. > This is reproducable with only untaring the sources and starting > configure script in R-devel with ./configure. The 'complex' type and rudimentary operations on complex numbers are supported, but the math library is missing all of the transcendental functions on complex numbers. There is some ongoing work in the area, but due to time constraints, it will likely be a while before we have complete support. In the mean time, you can see /usr/include/complex.h for a list of supported functions. I recall someone mentioning that there is a port that provides most of the missing functionality. From owner-freebsd-standards@FreeBSD.ORG Mon Feb 7 21:17:33 2011 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 9F5941065670 for ; Mon, 7 Feb 2011 21:17:33 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA228FC08 for ; Mon, 7 Feb 2011 21:17:32 +0000 (UTC) Received: from p57918d66.dip.t-dialin.net ([87.145.141.102] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1PmYSg-0004kX-OT; Mon, 07 Feb 2011 22:17:31 +0100 Message-ID: <4D506167.4020408@gwdg.de> Date: Mon, 07 Feb 2011 22:17:27 +0100 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.13) Gecko/20101218 Thunderbird/3.1.7 MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-standards@FreeBSD.org Subject: Re: Support for C99 complex type required X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:17:33 -0000 On 07.02.2011 20:02 (UTC+1), b. f. wrote: >> For more than a decade now it was possible to install the statistical >> program R (http://cran.r-project.org/) from the sources, even without >> patching. Since fortran was removed from the system, lang/gcc44 or >> lang/gcc45 has to be installed before. In addition a nice port exists >> for years now: math/R. >> >> With the new development version of R >> >> ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.gz >> >> the configure script stops complaining about missing C99 complex types. >> This is reproducable with only untaring the sources and starting >> configure script in R-devel with ./configure. >> >> There was a discussion on the R-devel mailing list about it. The >> developers came to the conclusion that there is no support for complex >> functions complied with C99 standard in FreeBSD. >> >> http://gcc.gnu.org/gcc-4.2/c99status.html >> >> As far as I can see (I am not a programmer) FreeBSD is using the old c99 >> wrapper file in /usr/bin. Am I right that lang/gcc45 should support such >> complex functions? >> >> http://gcc.gnu.org/gcc-4.5/c99status.html >> >> Is there any way to get access to C99 complex functions of gcc-4.5.3 or >> newer at least within a port? > > I am the math/R maintainer, and I do not subscribe to this list, > although I occasionally read it. Therefore it would be better to ask > me directly regarding questions about R, even if they are an > appropriate, in a wider sense, for this list. b.f., thank you very much for answering and sorry for not contacting you directly or at least via CC. Building R from sources works for me longer than a decade now without any trouble. R-devel (pre 2.13.0) is the first version complaining about missing C99 complex support. I asked about it on R-devel@ and after some discussion with several developers Murray Stokely advised me to open a thread at freebsd-standards@, so I did. At the time I opened this thread I wanted to ask in a more general way for C99 complex support. I used R as an example for my problem. > Yes, you can use some of the C99 complex machinery, enough to satisfy > R, which provides crude implementations of some of it if you have no > support for it otherwise (in, e.g., src/main/complex.c). But you > should use lang/gcc4* and the appropriate compiler flags -- if you are > using /usr/bin/c99, you are using the wrong compiler suite. The port > sets USE_FORTRAN=yes, which points R in the right direction. If you > are not a programmer, why not just use the port? Or, if you really > need the development version, why not use the port as a basis for your > own locally-patched port? Generally speaking, you cannot expect to > build software that is largely developed on other platforms without > some modifications. I like your port, but for some reason I prefer to build from sources. Over the years I found some smaller problems in upcoming versions of R, which could worked out with help from R developers before the release. I never expected that every new or upcoming release of R should work out of the box. But if I find a problem which prevents me from building such a version on FreeBSD, I take a look, eventually contact R-help@ or R-devel@ and always over the last 13 years we found a solution. Several times this led to some little new or special code in the R sources. > In any event, I too would like to see better support in the base > system for C99 math, which is being used by an increasing number of > software packages. It seems, in particular through the eyes of R developers, that FreeBSD is one of the last bigger OS leaking C99 complex support (Windows has, Linux has, Mac OS X has ...). Are you already working on a port for upcoming (hopefully in spring) R-2.13.0? > b. Thanks again, Rainer From owner-freebsd-standards@FreeBSD.ORG Wed Feb 9 21:09:35 2011 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 1AB52106566C for ; Wed, 9 Feb 2011 21:09:35 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2A048FC08 for ; Wed, 9 Feb 2011 21:09:34 +0000 (UTC) Received: by bwz12 with SMTP id 12so1354930bwz.13 for ; Wed, 09 Feb 2011 13:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:from:date:message-id :subject:to:content-type; bh=rGEv0El7o3H6Fj4BTcac9DoNMJgDgTyrMjWPmiWoHqw=; b=dTZcw+++rdKBzUV13Mi1zRvtTg5yExNKpuRpcvh6XxYbGCIhyYc/YJfJa+8NXtCXgY NiRL2S5WE3vWb3P7GA0yKAgoIg+h9IgQUHShBOoBQ/vvRUEEETY9YRLLyn9vfWQ+8DQ6 TJrEF5Aq3zScamSztfMDRAnUlk5c75cAlWhl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; b=d/aXz08etZUBKSluBFN/+9dMNxnUHU4dv6/YmaKFjenoYomt9cpJ+Y+o1hYfO/22No LGloc9IvEL3S9/RZUpfxIepSFh5tQIInIjLrHVZYuSWRYQQ5AGfRxq9MJUYnjF+rPJv0 goY0EasypYOPyq1h3o94VWfynKIM7X0cIUQXQ= Received: by 10.204.46.130 with SMTP id j2mr11334134bkf.169.1297284401363; Wed, 09 Feb 2011 12:46:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.76.18 with HTTP; Wed, 9 Feb 2011 12:46:11 -0800 (PST) From: Chris Rees Date: Wed, 9 Feb 2011 20:46:11 +0000 Message-ID: To: freebsd-standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Should we imitate GNU test's insanity? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:09:35 -0000 Hi all, I've found so many cases of autoconf failing when porting Linux apps over, for example scilab and musicpd due to the happiness of GNU test to accept a == b rather than a = b. Rather than making a bug report that'll be brushed off (as my bug report for GNU find was), would it be unthinkable for me to make a patch for our test to make == acceptable, to stop some wasted porters' time? Obviously our behaviour is correct [1], I just wonder if we're cutting off our noses so as to speak. Chris [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html From owner-freebsd-standards@FreeBSD.ORG Wed Feb 9 21:25:45 2011 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 6EB09106566C for ; Wed, 9 Feb 2011 21:25:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 14C3E8FC18 for ; Wed, 9 Feb 2011 21:25:45 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id E14EBA7D81D; Thu, 10 Feb 2011 05:25:43 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id 0Cx4aYGxzWna; Thu, 10 Feb 2011 05:25:37 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id C67EDA5AF95; Thu, 10 Feb 2011 05:25:36 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=uK9S39OZm/JIBLRWlYXFWvHFNV5hwtu/I+IgDxLkHtXslh912xmGBuRTU9ufON6Hl 9AIP9PuD+eUxG4eAihS8w== Message-ID: <4D53064B.7090901@delphij.net> Date: Wed, 09 Feb 2011 13:25:31 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101210 Thunderbird/3.0.11 ThunderBrowse/3.3.4 MIME-Version: 1.0 To: utisoft@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------070900030504060001050108" Cc: freebsd-standards@freebsd.org Subject: Re: Should we imitate GNU test's insanity? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:25:45 -0000 This is a multi-part message in MIME format. --------------070900030504060001050108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/09/11 12:46, Chris Rees wrote: > Hi all, > > I've found so many cases of autoconf failing when porting Linux apps > over, for example scilab and musicpd due to the happiness of GNU test > to accept a == b rather than a = b. > > Rather than making a bug report that'll be brushed off (as my bug > report for GNU find was), would it be unthinkable for me to make a > patch for our test to make == acceptable, to stop some wasted porters' > time? I don't think == is unacceptable extension to the POSIX standard based on my reading. If there is no objection I'll commit the attached patch on Friday. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJNUwZLAAoJEATO+BI/yjfB1jIH+gNDuwAebonOjVJeZi/RRsIb lnorgRDijI+y+Szo0av54TtlwTSlXK76hZEmmaK7R5cTK4NIQljIXKejVB9ZWYRY Setp+JHXNYCkc7tR6HqBwNjKUL3wLIjzxgMVPrAC2lAbDvk0kgz8VaysLFRpuj5F 7SmEaHUUhpzSRtlt27Ju06Y62r/+bRyWAiqeJFLZfNewJu6PIr+ZjAWU7M1ICFCy oNX2e7dx9AG8qGSZ0iJBYbyT0ITEQjWVtPFq4naFLHWAW/TfBxAWp5IwwXuAtdmF o4eapEIP7lB7t2Kxrn79+dFlf1yS1JgrvwlZBe6Ss87CiOnX1U4hPzqDLKPhTkw= =Q6K9 -----END PGP SIGNATURE----- --------------070900030504060001050108 Content-Type: text/plain; name="test.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.diff" Index: bin/test/test.c =================================================================== --- bin/test/test.c (revision 218497) +++ bin/test/test.c (working copy) @@ -140,6 +140,7 @@ {"-L", FILSYM, UNOP}, {"-S", FILSOCK,UNOP}, {"=", STREQ, BINOP}, + {"==", STREQ, BINOP}, {"!=", STRNE, BINOP}, {"<", STRLT, BINOP}, {">", STRGT, BINOP}, --------------070900030504060001050108-- From owner-freebsd-standards@FreeBSD.ORG Thu Feb 10 00:01:06 2011 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 D2800106566B for ; Thu, 10 Feb 2011 00:01:06 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 931228FC0C for ; Thu, 10 Feb 2011 00:01:06 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p1A00xFL095080; Wed, 9 Feb 2011 19:00:59 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p1A00xog095079; Wed, 9 Feb 2011 19:00:59 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 9 Feb 2011 19:00:59 -0500 From: David Schultz To: d@delphij.net Message-ID: <20110210000059.GA95033@zim.MIT.EDU> Mail-Followup-To: d@delphij.net, utisoft@gmail.com, freebsd-standards@freebsd.org References: <4D53064B.7090901@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D53064B.7090901@delphij.net> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Should we imitate GNU test's insanity? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:01:06 -0000 On Wed, Feb 09, 2011, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/09/11 12:46, Chris Rees wrote: > > Hi all, > > > > I've found so many cases of autoconf failing when porting Linux apps > > over, for example scilab and musicpd due to the happiness of GNU test > > to accept a == b rather than a = b. > > > > Rather than making a bug report that'll be brushed off (as my bug > > report for GNU find was), would it be unthinkable for me to make a > > patch for our test to make == acceptable, to stop some wasted porters' > > time? > > I don't think == is unacceptable extension to the POSIX standard based > on my reading. If there is no objection I'll commit the attached patch > on Friday. I agree; unobtrusive extensions that improve compatibility are welcome. From owner-freebsd-standards@FreeBSD.ORG Thu Feb 10 07:44:41 2011 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 6326D106566C for ; Thu, 10 Feb 2011 07:44:41 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E3DF48FC0C for ; Thu, 10 Feb 2011 07:44:40 +0000 (UTC) Received: by bwz12 with SMTP id 12so1743029bwz.13 for ; Wed, 09 Feb 2011 23:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=7PliiE6Q7Y0LQh3CCC3zcn4StQFZUFM9ggvHW1BIUtw=; b=kYiiGsA0zXpCq9TIXvTd3EVBc7oTF/bPpDqbXjnN3ofuxCZ3p8uoMyebGIuJZvM8SC DXMQ+IGAwwtmFtRj2Mg5DRNyCwqhxH8sv2ART55JpU0M6E1HXgDtb+lCFiHKW9sXV7vX oZFktLJdqB47EHvlKGaJpKvhELYnHyib+ITZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; b=np8wCiAX15EpmOiGaPRE20lXvOWQiF9tJviaqOuF99L8P93y88hntBwMUhE/dX7cs0 TT26+G4e88dNlpL6iIijOuwX8GftbfFRsCSJ284qmQ1fWEHwk3wg3gsyWaRcz7rP5SKu DaW+a5Gw+WPoLndg38K6dMGeodsYCDU13KOQc= Received: by 10.204.46.130 with SMTP id j2mr12010609bkf.169.1297323879693; Wed, 09 Feb 2011 23:44:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.76.18 with HTTP; Wed, 9 Feb 2011 23:44:09 -0800 (PST) In-Reply-To: <20110210000059.GA95033@zim.MIT.EDU> References: <4D53064B.7090901@delphij.net> <20110210000059.GA95033@zim.MIT.EDU> From: Chris Rees Date: Thu, 10 Feb 2011 07:44:09 +0000 Message-ID: To: d@delphij.net, utisoft@gmail.com, freebsd-standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Should we imitate GNU test's insanity? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:44:41 -0000 On 10 February 2011 00:00, David Schultz wrote: > On Wed, Feb 09, 2011, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 02/09/11 12:46, Chris Rees wrote: >> > Hi all, >> > >> > I've found so many cases of autoconf failing when porting Linux apps >> > over, for example scilab and musicpd due to the happiness of GNU test >> > to accept a =3D=3D b rather than a =3D b. >> > >> > Rather than making a bug report that'll be brushed off (as my bug >> > report for GNU find was), would it be unthinkable for me to make a >> > patch for our test to make =3D=3D acceptable, to stop some wasted port= ers' >> > time? >> >> I don't think =3D=3D is unacceptable extension to the POSIX standard bas= ed >> on my reading. =A0If there is no objection I'll commit the attached patc= h >> on Friday. > > I agree; unobtrusive extensions that improve compatibility are welcome. > Wow, that was quick. Thanks! Chris From owner-freebsd-standards@FreeBSD.ORG Thu Feb 10 08:49:22 2011 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 3252B106564A for ; Thu, 10 Feb 2011 08:49:21 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from erengrad.hoster.bg (erengrad.hoster.bg [77.77.142.9]) by mx1.freebsd.org (Postfix) with ESMTP id 70AB68FC14 for ; Thu, 10 Feb 2011 08:49:21 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by erengrad.hoster.bg (Postfix) with ESMTP id 029E0DCC93 for ; Thu, 10 Feb 2011 10:27:46 +0200 (EET) Received: from straylight.ringlet.net (unknown [95.111.66.80]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id 41B1D5CD38 for ; Thu, 10 Feb 2011 10:27:30 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 506695 by straylight.ringlet.net (DragonFly Mail Agent) Thu, 10 Feb 2011 10:27:29 +0200 Date: Thu, 10 Feb 2011 10:27:28 +0200 From: Peter Pentchev To: Chris Rees Message-ID: <20110210082725.GA2858@straylight.ringlet.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: 41B1D5CD38.DDC1E X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: freebsd-standards@freebsd.org X-Spam-Status: No Cc: freebsd-standards@freebsd.org Subject: Re: Should we imitate GNU test's insanity? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:49:22 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 09, 2011 at 08:46:11PM +0000, Chris Rees wrote: > Hi all, >=20 > I've found so many cases of autoconf failing when porting Linux apps > over, for example scilab and musicpd due to the happiness of GNU test > to accept a =3D=3D b rather than a =3D b. >=20 > Rather than making a bug report that'll be brushed off (as my bug > report for GNU find was), would it be unthinkable for me to make a > patch for our test to make =3D=3D acceptable, to stop some wasted porters' > time? >=20 > Obviously our behaviour is correct [1], I just wonder if we're cutting > off our noses so as to speak. >=20 > Chris >=20 > [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html Funny that this should come up right now - just a couple of days ago, a discussion started on the Austin Group list about extending test(1) with some widely-used operators. I wonder if we shouldn't wait a bit to see how that discussion turns out :) https://www.opengroup.org/sophocles/show_mail.tpl?source=3DL&listname=3Daus= tin-group-l&id=3D15271 For the follow-up discussion, see: https://www.opengroup.org/sophocles/show_archive.tpl?listname=3Daustin-grou= p-l (and of course, if anybody knows of another web-based archive for the Austin Group list that provides an easier way to see the follow-ups, please share a link :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org peter@packetscale.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Hey, out there - is it *you* reading me, or is it someone else? --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNU6FmAAoJEGUe77AlJ98T3Y8P/iGMxhIMY1V77kouQIDIdeiL TK2VsgnsneAFQigzFQ+iA7KIrzB32Y8UoL1j+64WM4AZTlF49SQLKc7IEVXG02Qm LOWifdvwAG5OP5XTrANzAeV1dPNvnY13U4Q/83lfuIMot7zn2FtR0exGSAbW5HxA hrVPskNw2XwFLmh0PbwQrZGSNwd8dQxILYoVOvIj7Efy5kzGZkGe/lqWluTjqPY1 bWClsnU3it65VUgX3Wa8TahxaruhE2ggdwdt3qmY6qWgaHz6Wi70hdhCu597SKAi nKw8FlJnbN+iYvNXrtMdknhYctJz2PMU2yFrZrlMfKnUD6Lzpheq62X2lIsFkzlD YGdhCDlhnTlJYpySJnsn3GQRIfQpoLfqdKLBlZJNB4elXK4UieuDKQi9Y29W2vLt JQHI1QryR1Yq0eYS0G9khTZAF5QjzM+A1UIrZOrG2h4aAI1MgEloRK94khMlTDrY fraK1YO3bzk/jQ4vbb+7zDhT0Qz7K4LdPxeQ/cZ1OoLSqjFemcRWIKVmrohPuZpa zWm/NUQxXGfRvZjhl5AypNwA/i5DIjwxDiL+Oy21HTJP0wLMuTYxhIOPxdEi7wMf oqlJ5hSSYXHlbnFRZSqIWuMeePhC3wFH1wpE99pxVhvhB9p1Iob3rzq6gYrvS8Xj 4ve35ZPUYTkPBqAhVEBB =CQ4X -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-standards@FreeBSD.ORG Sat Feb 12 21:16:56 2011 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 12C8A106564A; Sat, 12 Feb 2011 21:16:55 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A5ED68FC18; Sat, 12 Feb 2011 21:16:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1CLGtVR051991; Sat, 12 Feb 2011 21:16:55 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1CLGtJm051987; Sat, 12 Feb 2011 21:16:55 GMT (envelope-from brucec) Date: Sat, 12 Feb 2011 21:16:55 GMT Message-Id: <201102122116.p1CLGtJm051987@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-doc@FreeBSD.org, freebsd-standards@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: docs/143472: gethostname(3) references undefined value: HOST_NAME_MAX 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, 12 Feb 2011 21:16:56 -0000 Synopsis: gethostname(3) references undefined value: HOST_NAME_MAX Responsible-Changed-From-To: freebsd-doc->freebsd-standards Responsible-Changed-By: brucec Responsible-Changed-When: Sat Feb 12 21:07:39 UTC 2011 Responsible-Changed-Why: Standards PR. The specification is slightly confusing between gethostname and limits.h but ultimately clear that HOST_NAME_MAX can be ommitted and and that sysconf should be used. http://www.freebsd.org/cgi/query-pr.cgi?pr=143472 From owner-freebsd-standards@FreeBSD.ORG Sat Feb 12 21:40:07 2011 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 AAE26106564A for ; Sat, 12 Feb 2011 21:40: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 9A1218FC0A for ; Sat, 12 Feb 2011 21:40:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1CLe7bh072806 for ; Sat, 12 Feb 2011 21:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1CLe7vg072805; Sat, 12 Feb 2011 21:40:07 GMT (envelope-from gnats) Date: Sat, 12 Feb 2011 21:40:07 GMT Message-Id: <201102122140.p1CLe7vg072805@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Bruce Cran Cc: Subject: Re: docs/143472 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 21:40:07 -0000 The following reply was made to PR docs/143472; it has been noted by GNATS. From: Bruce Cran To: bug-followup@freebsd.org Cc: Subject: Re: docs/143472 Date: Sat, 12 Feb 2011 21:34:14 +0000 --Boundary-00=_WzvVNhmY4S2KrEV Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've attached a patch which should fix the issue. -- Bruce Cran --Boundary-00=_WzvVNhmY4S2KrEV Content-Type: text/plain; charset="ISO-8859-1"; name="gethostname.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gethostname.diff.txt" Index: gen/gethostname.3 =================================================================== --- gen/gethostname.3 (revision 218613) +++ gen/gethostname.3 (working copy) @@ -47,7 +47,7 @@ The .Fn gethostname function -returns the standard host name for the current processor, as +returns the standard host name for the current machine, as previously set by .Fn sethostname . The @@ -68,9 +68,9 @@ This call is restricted to the super-user and is normally used only when the system is bootstrapped. .Pp -Host names are limited to -.Brq Dv HOST_NAME_MAX -characters, not including the trailing null, currently 255. +Applications should use +.Fn sysconf _SC_HOST_NAME_MAX +to find the maximum length of a host name (not including the terminating null). .Sh RETURN VALUES .Rv -std .Sh ERRORS --Boundary-00=_WzvVNhmY4S2KrEV-- From owner-freebsd-standards@FreeBSD.ORG Sat Feb 12 22:45:40 2011 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 99A55106566B; Sat, 12 Feb 2011 22:45:40 +0000 (UTC) (envelope-from wollman@csail.mit.edu) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by mx1.freebsd.org (Postfix) with ESMTP id 70E5A8FC0C; Sat, 12 Feb 2011 22:45:40 +0000 (UTC) Received: from dsl092-079-129.bos1.dsl.speakeasy.net ([66.92.79.129] helo=[192.168.1.3]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PoNmH-00024Y-MR; Sat, 12 Feb 2011 17:17:17 -0500 References: <201102122116.p1CLGtJm051987@freefall.freebsd.org> (sfid-20110212_16171_2435D605) User-Agent: K-9 Mail for Android In-Reply-To: <201102122116.p1CLGtJm051987@freefall.freebsd.org> (sfid-20110212_16171_2435D605) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Garrett Wollman Date: Sat, 12 Feb 2011 17:17:16 -0500 To: brucec@freebsd.org,freebsd-doc@freebsd.org,freebsd-standards@freebsd.org Message-ID: <36a85352-9802-460b-b616-00cf9f9e502f@email.android.com> Cc: Subject: Re: docs/143472: gethostname(3) references undefined value: HOST_NAME_MAX 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, 12 Feb 2011 22:45:40 -0000 brucec@freebsd.org wrote: >Standards PR. The specification is slightly confusing between >gethostname >and limits.h but ultimately clear that HOST_NAME_MAX can be ommitted >and >and that sysconf should be used. The Standard uses special typography to indicate these parameters; we should, too. _GAWollman From owner-freebsd-standards@FreeBSD.ORG Sat Feb 12 22:45:42 2011 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 E975F106564A for ; Sat, 12 Feb 2011 22:45:42 +0000 (UTC) (envelope-from wollman@csail.mit.edu) Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) by mx1.freebsd.org (Postfix) with ESMTP id C48008FC12 for ; Sat, 12 Feb 2011 22:45:42 +0000 (UTC) Received: from dsl092-079-129.bos1.dsl.speakeasy.net ([66.92.79.129] helo=[192.168.1.3]) by outgoing.csail.mit.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PoNp2-00025X-5e; Sat, 12 Feb 2011 17:20:08 -0500 References: <201102122140.p1CLe7vg072805@freefall.freebsd.org> (sfid-20110212_16402_8B3946F8) User-Agent: K-9 Mail for Android In-Reply-To: <201102122140.p1CLe7vg072805@freefall.freebsd.org> (sfid-20110212_16402_8B3946F8) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Garrett Wollman Date: Sat, 12 Feb 2011 17:20:07 -0500 To: Bruce Cran ,freebsd-standards@freebsd.org Message-ID: <7670d9f9-77ea-41b0-9cdc-58122ebc9156@email.android.com> Cc: Subject: Re: docs/143472 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, 12 Feb 2011 22:45:43 -0000 Bruce Cran wrote: > I've attached a patch which should fix the issue. > -Host names are limited to > -.Brq Dv HOST_NAME_MAX > -characters, not including the trailing null, currently 255. This is actually the correct statement. The OP should have taken note of the braces. -GAWollman From owner-freebsd-standards@FreeBSD.ORG Sat Feb 12 23:18:44 2011 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 2F271106566C; Sat, 12 Feb 2011 23:18:44 +0000 (UTC) (envelope-from brucec@freebsd.org) Received: from muon.cran.org.uk (unknown [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 2066B8FC18; Sat, 12 Feb 2011 23:18:43 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 66039E82B6; Sat, 12 Feb 2011 23:18:38 +0000 (GMT) Received: from core.nessbank (client-86-31-165-87.oxfd.adsl.virginmedia.com [86.31.165.87]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 2FB50E8266; Sat, 12 Feb 2011 23:18:38 +0000 (GMT) From: Bruce Cran To: Garrett Wollman Date: Sat, 12 Feb 2011 23:18:17 +0000 User-Agent: KMail/1.13.5 (FreeBSD/9.0-CURRENT; KDE/4.5.5; amd64; ; ) References: <201102122116.p1CLGtJm051987@freefall.freebsd.org> <36a85352-9802-460b-b616-00cf9f9e502f@email.android.com> In-Reply-To: <36a85352-9802-460b-b616-00cf9f9e502f@email.android.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_5UxVNPXsKxAJLIv" Message-Id: <201102122318.17338.brucec@freebsd.org> Cc: freebsd-doc@freebsd.org, freebsd-standards@freebsd.org Subject: Re: docs/143472: gethostname(3) references undefined value: HOST_NAME_MAX 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, 12 Feb 2011 23:18:44 -0000 --Boundary-00=_5UxVNPXsKxAJLIv Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Saturday 12 February 2011 22:17:16 Garrett Wollman wrote: > The Standard uses special typography to indicate these parameters; we > should, too. Having done further reading on opengroup.org I realised that the brackets do indicate that it's a value that can be obtained through sysconf(3). However, it's not especially clear to readers unfamiliar with the Standard, and has confused people in the past - for example http://www.mail- archive.com/bug-gnulib@gnu.org/msg14789.html . I wonder if there's a way we can improve the documentation to make it clear that these values aren't necessarily preprocessor definitions? I've attached a patch to sysconf(3) which adds documentation of {HOST_NAME_MAX} and others. -- Bruce Cran --Boundary-00=_5UxVNPXsKxAJLIv Content-Type: text/plain; charset="ISO-8859-1"; name="sysconf.3.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysconf.3.diff.txt" Index: sysconf.3 =================================================================== --- sysconf.3 (revision 218613) +++ sysconf.3 (working copy) @@ -28,7 +28,7 @@ .\" @(#)sysconf.3 8.3 (Berkeley) 4/19/94 .\" $FreeBSD$ .\" -.Dd December 14, 2006 +.Dd Febuary 12, 2011 .Dt SYSCONF 3 .Os .Sh NAME @@ -85,6 +85,9 @@ The maximum number of open files per user id. .It Li _SC_PAGESIZE The size of a system page in bytes. +.It Li _SC_PAGE_SIZE +Equivalent to +.It Li _SC_PAGESIZE . .It Li _SC_STREAM_MAX The minimum maximum number of streams that a process may have open at any one time. @@ -160,10 +163,68 @@ .It Li _SC_2_UPE Return 1 if the system supports the User Portability Utilities Option, otherwise \-1. +.It Li _SC_AIO_LISTIO_MAX +Maximum number of I/O operations in a single list I/O call supported. +.It Li _SC_AIO_MAX +Maximum number of outstanding asynchronous I/O operations supported. +.It Li _SC_AIO_PRIO_DELTA_MAX +The maximum amount by which a process can decrease its asynchronous I/O +priority level from its own scheduling priority. +.It Li _SC_DELAYTIMER_MAX +Maximum number of timer expiration overruns. +.It Li _SC_MQ_OPEN_MAX +The maximum number of open message queue descriptors a process may hold. +.It Li _SC_RTSIG_MAX +Maximum number of realtime signals reserved for application use. +.It Li _SC_SEM_NSEMS_MAX +Maximum number of semaphores that a process may have. +.It Li _SC_SEM_VALUE_MAX +The maximum value a semaphore may have. +.It Li _SC_SIGQUEUE_MAX +Maximum number of queued signals that a process may send and have pending at +the receiver(s) at any time. +.It Li _SC_TIMER_MAX +Maximum number of timers per process supported. +.It Li _SC_GETGR_R_SIZE_MAX +Suggested initial value for the size of the buffer required for a call to +.Fn getgr +functions or -1. +.It Li _SC_GETPW_R_SIZE_MAX +Suggested initial value for the size of the buffer required for a call to +.Fn getpw +functions or -1. +.It Li _SC_HOST_NAME_MAX +Maximum length of a host name (not including the terminating null) as +returned from the +.Fn gethostname +function. +.It Li _SC_LOGIN_NAME_MAX +Maximum length of a login name. +.It Li _SC_THREAD_STACK_MIN +Minimum size in bytes of thread stack storage. +.It Li _SC_THREAD_THREADS_MAX +Maximum number of threads that can be created per process. +.It Li _SC_TTY_NAME_MAX +Maximum length of terminal device name. +.It Li _SC_SYMLOOP_MAX +Maximum number of symbolic links that can be reliably traversed in the +resolution of a pathname in the absence of a loop. +.It Li _SC_ATEXIT_MAX +Maximum number of functions that may be registered with +.Fn atexit . +.It Li _SC_XOPEN_VERSION +An integer value greater than or equal to 4, +indicating the version of the X/Open Portability Guide to which this +system conforms. +.It Li _SC_XOPEN_XCU_VERSION +An integer value indicating the version of the XCU Specification to which +this system conforms. .El .Pp These values also exist, but may not be standard: .Bl -tag -width 6n +.It Li _SC_CPUSET_SIZE +Size of the kernel cpuset. .It Li _SC_PHYS_PAGES The number of pages of physical memory. Note that it is possible that the product of this value and the value of --Boundary-00=_5UxVNPXsKxAJLIv--