This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: safe string copy and concetation


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]