This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: safe string copy and concetation
- To: libc-alpha at sources dot redhat dot com
- Subject: Re: PATCH: safe string copy and concetation
- From: Chiaki Ishikawa <Chiaki dot Ishikawa at personal-media dot co dot jp>
- Date: Thu, 10 Aug 2000 21:10:51 +0900 (JST)
X-PMC-CI-e-mail-id: 13410
>> Certainly, strlcpy is easy:
>>
>> #define strlcpy(a, b, c) sprintf(a, "%.*s", b, (int) ((c)-1))
>>
>> Did I get that right? The idea is to copy at most c-1 characters from string a
>
>On second reading, no I didn't! The int parameter must precede the char * one.
>Oops! :)
Well, aside from getting these routines right at the first try,
I can think of a few reasons why having strlcpy and friends
in a standard library may be useful.
(0. As I mentioned, these functions certainly are useful for
stop-gap band-aid and having a correct implementation therein
would be useful.)
1. Since similar routines are needed anyway for reliable
programs (and maintenance reasons), why don't we include
well-documented strlcpy and friends.
Here I refer to the document such as the paper presented at
Usenix conference.
2. Having a common set of routines used for similar purposes
in a library promotes re-use and shared knowledge among
the programming community.
I can't stress the point 1 above too much.
Having a set of usable routines is one thing, but
providing a set of document(s) that explain the purpose
and examples of such routines is totally another.
In the case of strlcpy and friends, this has been
more or less taken care of.
The main reason why I wished strlcpy and friends were
available a few years ago when Bnews on SunOS 4.1.x
began to behave erratically is that
by using well-documented strlcpy and friends, my modification
would have been easider to understand to the possible
future local maintainer provided that these people have read the
document about strlcpy or that I would pass them the document.
(We got rid of Bnews sometime later, though...)
Anyway, I think Solaris 8 libc seems to include these functions and
so we expect the usage to increase.
This reason alone might be worth reconsideration.
Just my two cents worth.
--
Ishikawa, Chiaki ishikawa@personal-media.co.jp.NoSpam or
(family name, given name) Chiaki.Ishikawa@personal-media.co.jp.NoSpam
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051