Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Apr 2008 01:20:11 +0300
From:      Giorgos Keramidas <keramida@ceid.upatras.gr>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        Simun Mikecin <numisemis@yahoo.com>, freebsd-hackers@freebsd.org, Mike Meyer <mwm@mired.org>, hackers@freebsd.org
Subject:   Re: strdup(NULL) supposed to create SIGSEGV?
Message-ID:  <878wz49pt0.fsf@kobe.laptop>
In-Reply-To: <200804231957.49035.hselasky@c2i.net> (Hans Petter Selasky's message of "Wed, 23 Apr 2008 19:57:47 %2B0200")
References:  <293918.47889.qm@web36608.mail.mud.yahoo.com> <20080423124023.54ca505e@mbook-fbsd> <200804231957.49035.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Apr 2008 19:57:47 +0200, Hans Petter Selasky <hselasky@c2i.net> =
wrote:
> Hi,
>
> I recently had to tell someone that "strncpy" does not always zero
> terminate the destination string. Surprised by what I was telling they
> immediately wanted to change the way the function worked. When a
> function is defined by an ISO standard you are not supposed to change
> the definition. Instead I pointed the person at "strlcpy". Else you
> will have serious trouble when code is ported to a new platform.
>
> http://www.gratisoft.us/todd/papers/strlcpy.html
>
> The name "strdup" is very appealing, but it has already been taken and
> defined. You have to give your variant a different name and convince
> everyone that your function is good and solves a problem so that it
> deserves to be in the C-library.

Right on the spot, Hans :)

You may have to pick a name that doesn't start from "str", though,
because the "str*" function names are reserved for future extensions to
the standard.  ISO/IEC 9899:1999 (E), page 401, =C2=A77.26.11 says:

    7.26 Future library directions
    [...]
    7.26.11 String handling <string.h>

    1   Function names that begin with "str", "mem", or "wcs" and a
        lowercase letter may be added to the declarations in the
        <string.h>  header.

You're quite right about 'not replacing' the standard functions in a
lighthearted manner though.  The short-term benefits of making a single
application "easier to write", are dwarfed by the possibilities for
introducing gratuitous incompatibilities for all the _other_ programs
running on the same platform, and any other platforms conforming to the
"real" standard behavior.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?878wz49pt0.fsf>