From owner-svn-src-head@FreeBSD.ORG Wed Feb 4 11:28:04 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A896106566B; Wed, 4 Feb 2009 11:28:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id E6D708FC08; Wed, 4 Feb 2009 11:28:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-107-120-227.carlnfd1.nsw.optusnet.com.au (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n14BRx1f020559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Feb 2009 22:28:01 +1100 Date: Wed, 4 Feb 2009 22:27:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Christoph Mallon In-Reply-To: <4988AB83.2050203@gmx.de> Message-ID: <20090204212854.F51932@delplex.bde.org> References: <200902032025.n13KPaCV041012@svn.freebsd.org> <4988AB83.2050203@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Warner Losh Subject: Re: svn commit: r188098 - head/lib/libc/string X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 11:28:04 -0000 On Tue, 3 Feb 2009, Christoph Mallon wrote: > Warner Losh schrieb: >> Modified: head/lib/libc/string/strmode.c >> ============================================================================== >> --- head/lib/libc/string/strmode.c Tue Feb 3 20:01:51 2009 >> (r188097) >> +++ head/lib/libc/string/strmode.c Tue Feb 3 20:25:36 2009 >> (r188098) >> @@ -38,7 +38,7 @@ __FBSDID("$FreeBSD$"); >> #include >> void >> -strmode(mode_t mode, char *p) >> +strmode(/* mode_t */ int mode, char *p) >> { >> /* print type */ >> switch (mode & S_IFMT) { > > The manpage states that the first parameter of strmode() is a mode_t. What's > wrong - the implementation (both in header and definition) or the > documentation? The man page is wrong. strtomode() should take an int arg (actually the default (unary) promotion of a mode_t) for the the same reasons that memchr() does -- because these interfaces should be usable by K&R compilers and/or by standard C compilers without a protoype in scope. Even if this is no longer required, binary compatibily requires the interfaces to be the same as the ones that used to be required. The requirement for binary compatibility also prevents "fixing" interfaces to be "ANSI" in headers (if you "fix" prototypes there then you will get obscure runtime errors instead of tinderbox errors). mode_t causes even more problems on systems with 16-bit ints since its default promotion is unsigned int. Thus the correct declaration of strmode() is machine-dependent. Similarly for memchr() on systems with sizeof(char) == sizeof(int). Standard C doesn't support variant interfaces so memchr() cannot work quite right on such systems. This problem used to be much larger for POSIX. POSIX.1-1988 didn't require prototypes, but it required use of mode_t and lots of other probably-sub-integer typedefed types too much in its interfaces (unlike standard C which uses ints and longs too much), and it declares all its interfaces using prototypes so the ones that involve sub-integer types cannot be implemented by either K&R compilers or Standard C compilers (for K&R, sub-integer types are not supported, and for Standard C the literal prototypes don't match the default promotions). Now, POSIX requires prototypes (to be supported by the compiler), and, like standard C, it requires a prototype to be in scope if the type of any function parameter is incompatible with its default promotion, so the problems are limited mainly to loss of bits on exotic machines in the forced conversions between signed and unsigned values. Since the prototypes aren't variant, sometimes there are forced conversions that mess up the values even if the initial and final types are the same. I probably missed fixing strmode.3 because of the gcc bug that you pointed out -- the prototype is incompatible with the declaration in strmode.3, so the behaviour is undefined, but gcc's implementation of the undefined behaviour is to do the right thing if a prototype is in scope and to do the wrong thing if a prototype is not in scope. Since my man page checker puts the wrong prototype in scope but doesn't put the correct prototype from string.h in scope, the error goes undetected. Bruce