Date: Wed, 04 Feb 2009 15:44:14 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Christoph Mallon <christoph.mallon@gmx.de>, Warner Losh <imp@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r188098 - head/lib/libc/string Message-ID: <20090204154414.1949765y56lfhi80@webmail.leidinger.net> In-Reply-To: <20090204212854.F51932@delplex.bde.org> References: <200902032025.n13KPaCV041012@svn.freebsd.org> <4988AB83.2050203@gmx.de> <20090204212854.F51932@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Bruce Evans <brde@optusnet.com.au> (from Wed, 4 Feb 2009 =20 22:27:59 +1100 (EST)): > On Tue, 3 Feb 2009, Christoph Mallon wrote: > >> Warner Losh schrieb: >>> Modified: head/lib/libc/string/strmode.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> --- head/lib/libc/string/strmode.c=09Tue Feb 3 20:01:51 2009 (r188097) >>> +++ head/lib/libc/string/strmode.c=09Tue 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) >>> { >>> =09 /* print type */ >>> =09switch (mode & S_IFMT) { >> >> The manpage states that the first parameter of strmode() is a =20 >> mode_t. What's wrong - the implementation (both in header and =20 >> 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 =20 libc? I thought this is supposed to "fix" this problem (assuming we =20 add an UPDATING entry that users have to make sure that they to a full =20 installworld to habe the includes and the lib in sync)? Bye, Alexander. --=20 Sometimes the best medicine is to stop taking something. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090204154414.1949765y56lfhi80>