svn commit: r188098 - head/lib/libc/string

Alexander Leidinger Alexander at Leidinger.net
Wed Feb 4 22:22:07 PST 2009


Quoting "M. Warner Losh" <imp at bsdimp.com> (from Wed, 04 Feb 2009  
10:32:20 -0700 (MST)):

> In message: <20090204154414.1949765y56lfhi80 at webmail.leidinger.net>
>             Alexander Leidinger <Alexander at leidinger.net> writes:
> : Quoting Bruce Evans <brde at optusnet.com.au> (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 <string.h>
> : >>>  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.

Bye,
Alexander.

-- 
Phosflink, v:
	To flick a bulb on and off when it burns out (as if, somehow,
	that will bring it back to life).
		-- Rich Hall & Friends, "Sniglets"

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the svn-src-all mailing list