From owner-svn-src-head@FreeBSD.ORG Thu Feb 5 07:51:18 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 3F3031065672; Thu, 5 Feb 2009 07:51:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id CB23A8FC0C; Thu, 5 Feb 2009 07:51:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n157mLYZ012273; Thu, 5 Feb 2009 00:48:21 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 05 Feb 2009 00:48:49 -0700 (MST) Message-Id: <20090205.004849.-906919470.imp@bsdimp.com> To: Alexander@leidinger.net From: "M. Warner Losh" In-Reply-To: <20090205072158.23811u1p5tpfkakk@webmail.leidinger.net> References: <20090204154414.1949765y56lfhi80@webmail.leidinger.net> <20090204.103220.1763804960.imp@bsdimp.com> <20090205072158.23811u1p5tpfkakk@webmail.leidinger.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, christoph.mallon@gmx.de, src-committers@freebsd.org, brde@optusnet.com.au 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: Thu, 05 Feb 2009 07:51:18 -0000 In message: <20090205072158.23811u1p5tpfkakk@webmail.leidinger.net> Alexander Leidinger writes: : Quoting "M. Warner Losh" (from Wed, 04 Feb 2009 : 10:32:20 -0700 (MST)): : : > In message: <20090204154414.1949765y56lfhi80@webmail.leidinger.net> : > Alexander Leidinger writes: : > : Quoting Bruce Evans (from Wed, 4 Feb 2009 : > : 22:27:59 +1100 (EST)): : > : : > : > 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). : > : : > : Is this also true for the current use of symbol versioning in our : > : libc? I thought this is supposed to "fix" this problem (assuming we : > : add an UPDATING entry that users have to make sure that they to a full : > : installworld to habe the includes and the lib in sync)? : > : > Maybe, but it is a problem worth fixing? What we have now is correct : : It depends if this is seen as a broken window : (http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy) : or not... : : At least we should not talk a lot against fixing it. If someone wants : to fix it, he should be welcome. Yea. A lot of hair to get right, to test, and to make sure works everywhere. If someone has that, and can still make things work in the no-prototype case, then go for it. Warner