Date: Wed, 04 Feb 2009 10:32:20 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: Alexander@leidinger.net 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 Message-ID: <20090204.103220.1763804960.imp@bsdimp.com> In-Reply-To: <20090204154414.1949765y56lfhi80@webmail.leidinger.net> References: <4988AB83.2050203@gmx.de> <20090204212854.F51932@delplex.bde.org> <20090204154414.1949765y56lfhi80@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20090204154414.1949765y56lfhi80@webmail.leidinger.net>
Alexander Leidinger <Alexander@leidinger.net> writes:
: Quoting Bruce Evans <brde@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
for both cases (prototypes and no prototypes) on all the architectures
that FreeBSD supports (or even kinda supports). Does it make sense to
add a lot of extra hair just to have a slightly more proper prototype?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090204.103220.1763804960.imp>