From owner-freebsd-standards@FreeBSD.ORG Mon May 9 11:01:50 2005 Return-Path: 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 6D7FC16A505 for ; Mon, 9 May 2005 11:01:50 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4917F43D7E for ; Mon, 9 May 2005 11:01:50 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j49B1otK097756 for ; Mon, 9 May 2005 11:01:50 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j49B1n7h097748 for freebsd-standards@freebsd.org; Mon, 9 May 2005 11:01:49 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 9 May 2005 11:01:49 GMT Message-Id: <200505091101.j49B1n7h097748@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 11:01:51 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string p [2002/02/25] standards/35307standards standard include files are not standard c o [2002/12/13] kern/46239 standards posix semaphore implementation errors o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2004/01/01] standards/60772standards _Bool and bool should be unsigned o [2004/11/03] standards/73500standards 'set +o' in /bin/sh does not include unse o [2005/03/03] standards/78357standards getaddrinfo() doesn't appear to support A o [2005/03/09] standards/78650standards ttyname_r() is not standards compliant o [2005/03/16] standards/78907standards does not define pthread typ 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/01/24] standards/24590standards timezone function not compatible witn Sin s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public p [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant o [2002/02/27] misc/35381 standards incorrect floating-point display of large s [2002/03/19] standards/36076standards Implementation of POSIX fuser command o [2002/06/14] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] kern/40378 standards stdlib.h gives needless warnings with -an p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/25] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/07/31] standards/55112standards glob.h, glob_t's gl_pathc should be "size o [2003/09/05] standards/56476standards cd9660 unicode support simple hack o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname p [2003/12/26] standards/60597standards FreeBSD's /usr/include lacks of cpio.h s [2004/02/14] standards/62858standards malloc(0) not C99 compliant p [2004/02/21] standards/63173standards Patch to add getopt_long_only(3) to libc o [2004/03/29] kern/64875 standards [patch] add a system call: fdatasync() o [2004/05/07] standards/66357standards make POSIX conformance problem ('sh -e' & o [2004/05/11] standards/66531standards _gettemp uses a far smaller set of filena o [2004/08/22] standards/70813standards [PATCH] ls not Posix compliant o [2004/08/26] docs/70985 standards [patch] sh(1): incomplete documentation o o [2004/09/22] standards/72006standards floating point formating in non-C locales o [2005/03/20] standards/79055standards Add an IFS regression test for shells o [2005/03/20] standards/79056standards regex(3) regression tests o [2005/03/21] standards/79067standards /bin/sh should be more intelligent about 30 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon May 9 15:55:20 2005 Return-Path: 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 3015C16A4E8; Mon, 9 May 2005 15:55:20 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 269F543D49; Mon, 9 May 2005 15:55:19 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)j49Ft3jO061330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2005 00:55:07 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 10 May 2005 00:55:01 +0900 Message-ID: From: Hajimu UMEMOTO To: David Schultz In-Reply-To: <20050503224409.GA16252@VARK.MIT.EDU> References: <20050503224409.GA16252@VARK.MIT.EDU> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 10 May 2005 00:55:07 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheer.mahoroba.org cc: arch@FreeBSD.ORG cc: standards@FreeBSD.ORG cc: Hajimu UMEMOTO Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 15:55:20 -0000 Hi, >>>>> On Tue, 3 May 2005 18:44:09 -0400 >>>>> David Schultz said: das> - You should use socklen_t instead of uint32_t, as appropriate. Are you mean netent.n_net? If so, it is because of POSIX. das> - It's probably better to use the machine/endian.h macros to test das> endianness instead of hard-coding every architecture. Yes. How about this patch? --- include/netdb.h.orig Thu Apr 28 04:12:56 2005 +++ include/netdb.h Mon May 9 15:45:55 2005 @@ -63,6 +63,8 @@ #include #include +#include +#include #ifndef _SIZE_T_DECLARED typedef __size_t size_t; @@ -74,6 +76,11 @@ #define _SOCKLEN_T_DECLARED #endif +#ifndef _UINT32_T_DECLARED +typedef __uint32_t uint32_t; +#define _UINT32_T_DECLARED +#endif + #ifndef _PATH_HEQUIV # define _PATH_HEQUIV "/etc/hosts.equiv" #endif @@ -99,14 +106,27 @@ }; /* - * Assumption here is that a network number - * fits in an unsigned long -- probably a poor one. + * Note: n_net used to be an unsigned long integer. + * In XNS5, and subsequently in POSIX-2001 it was changed to an + * uint32_t. + * To accomodate for this while preserving binary compatibility with + * the old interface, we prepend or append 32 bits of padding, + * depending on the (LP64) architecture's endianness. + * + * This should be deleted the next time the libc major number is + * incremented. */ struct netent { char *n_name; /* official name of net */ char **n_aliases; /* alias list */ int n_addrtype; /* net address type */ - unsigned long n_net; /* network # */ +#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN + uint32_t __n_pad0; /* ABI compatibility */ +#endif + uint32_t n_net; /* network # */ +#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN + uint32_t __n_pad0; /* ABI compatibility */ +#endif }; struct servent { @@ -122,12 +142,29 @@ int p_proto; /* protocol # */ }; +/* + * Note: ai_addrlen used to be a size_t, per RFC 2553. + * In XNS5.2, and subsequently in POSIX-2001 and RFC 3493 it was + * changed to a socklen_t. + * To accomodate for this while preserving binary compatibility with the + * old interface, we prepend or append 32 bits of padding, depending on + * the (LP64) architecture's endianness. + * + * This should be deleted the next time the libc major number is + * incremented. + */ struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ - size_t ai_addrlen; /* length of ai_addr */ +#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN + uint32_t __ai_pad0; /* ABI compatibility */ +#endif + socklen_t ai_addrlen; /* length of ai_addr */ +#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN + uint32_t __ai_pad0; /* ABI compatibility */ +#endif char *ai_canonname; /* canonical name for hostname */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ @@ -225,7 +262,7 @@ struct hostent *gethostent(void); struct hostent *getipnodebyaddr(const void *, size_t, int, int *); struct hostent *getipnodebyname(const char *, int, int, int *); -struct netent *getnetbyaddr(unsigned long, int); +struct netent *getnetbyaddr(uint32_t, int); struct netent *getnetbyname(const char *); struct netent *getnetent(void); int getnetgrent(char **, char **, char **); das> -#if 1 /* obsolete */ das> +#if __BSD_VISIBLE /* obsolete */ das> #define NI_WITHSCOPEID 0x00000020 das> #endif It reminds me one more issue. I wish to nuke NI_WITHSCOPEID before 6.0-RELEASE. NetBSD and OpenBSD did so already. das> +int getaddrinfo(const char * __restrict, const char * __restrict, das> + const struct addrinfo * __restrict, das> + struct addrinfo ** __restrict); das> +int getnameinfo(const struct sockaddr * __restrict, socklen_t, das> + char * __restrict, __size_t, char * __restrict, das> + __size_t, int); The 4th and 6th arguments are buffer length for return value, and they are size_t in spec. So, they should not be mixuped with others. das> -struct hostent *getipnodebyaddr(const void *, size_t, int, int *); das> +struct hostent *getipnodebyaddr(const void *, __size_t, int, int *); It is thorny issue. I think it is a bug, and it should be int. However, getipnodebyaddr() was defined in RFC 2553, then was deprecated in RFC 3493. So, I think it will never be revised. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-standards@FreeBSD.ORG Mon May 9 16:06:31 2005 Return-Path: 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 0378E16A4E8; Mon, 9 May 2005 16:06:31 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D6F43D93; Mon, 9 May 2005 16:06:30 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)j49G6Hpr013396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 May 2005 01:06:18 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 10 May 2005 01:06:16 +0900 Message-ID: From: Hajimu UMEMOTO To: Peter Wemm In-Reply-To: <200505041529.36826.peter@wemm.org> References: <200505041529.36826.peter@wemm.org> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 10 May 2005 01:06:18 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheer.mahoroba.org cc: standards@freebsd.org cc: current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 16:06:31 -0000 Hi, >>>>> On Wed, 4 May 2005 15:29:36 -0700 >>>>> Peter Wemm said: peter> Like David Schultz said, it would be better to use the machine/endian.h peter> macros to set the padding position. I think so, too, thanks. peter> As far as removing the padding goes, it makes little difference whether peter> you break it now or later. Doing it now will be painful. Doing it peter> before 6.0-REL will be just as painful. Not only is this encoded in peter> libc.so.6, but all applications and shared libraries that have exposure peter> to this also know it. Are you suggest when to remove padding? Since the major of libc was bumped already in 6-CURRENT, it may better to wait 7-CURRENT. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-standards@FreeBSD.ORG Mon May 9 16:43:54 2005 Return-Path: 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 A612E16A4EB; Mon, 9 May 2005 16:43:54 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 172A843D62; Mon, 9 May 2005 16:43:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j49GgYdb053165; Mon, 9 May 2005 10:42:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 09 May 2005 10:42:34 -0600 (MDT) Message-Id: <20050509.104234.71141880.imp@bsdimp.com> To: ume@freebsd.org From: Warner Losh In-Reply-To: References: <200505041529.36826.peter@wemm.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: standards@freebsd.org cc: current@freebsd.org cc: peter@wemm.org cc: freebsd-arch@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 16:43:54 -0000 > Are you suggest when to remove padding? Since the major of libc was > bumped already in 6-CURRENT, it may better to wait 7-CURRENT. We've generally not worried compatibility in the 'rough and tumble' world of FreeBSD current. So unless there's a problem in the upgrade path, I think that we safely omit them. Warner From owner-freebsd-standards@FreeBSD.ORG Wed May 11 06:40:31 2005 Return-Path: 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 D89C016A4CE; Wed, 11 May 2005 06:40:30 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3317243D1F; Wed, 11 May 2005 06:40:30 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 08:40:26 +0200 Date: Wed, 11 May 2005 08:40:29 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Andrey Chernov In-Reply-To: <20050510215930.GA81549@nagual.pp.ru> Message-ID: <20050511083434.B2955@beagle.kn.op.dlr.de> References: <200505100806.j4A86Edq046232@repoman.freebsd.org> <20050510210440.GT51193@elvis.mu.org> <20050510215930.GA81549@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 11 May 2005 06:40:26.0203 (UTC) FILETIME=[5091A2B0:01C555F4] cc: cvs-src@FreeBSD.ORG cc: standards@freebsd.org cc: Alfred Perlstein cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/make main.c var.c var.h X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2005 06:40:31 -0000 [CC to standards] On Wed, 11 May 2005, Andrey Chernov wrote: AC>On Tue, May 10, 2005 at 02:04:40PM -0700, Alfred Perlstein wrote: AC>> What about a flag/variable that if set enables "full POSIX mode"? AC> AC>Better environment variable with the same name like in GNU utils. You should look up the discussion that took place in standards@ last year or so. There have been some good arguments against using an environment variable. It might be better to use the approach other systems like Solaris use and put the Posix tools (together with man pages, libraries, whatever) into their own directory (/usr/posix, for example). To be honest, I have no idea what the best approach is. There are also others (use a system wide or user configuration file, for example). harti