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: Fri, 11 Aug 2000 22:00:40 +0900 (JST)
X-PMC-CI-e-mail-id: 13420
>X-PMC-CI-e-mail-id: 13410
>
>>> Certainly, strlcpy is easy:
>>>
>>> #define strlcpy(a, b, c) sprintf(a, "%.*s", b, (int) ((c)-1))
>>>
>
>No, no, no! You guys ever read the original documentation!?
*MY* post didn't mention that the macro seems to be very buggy
indeed. I think I should have been more explicit, but I thought
many would see the problem immediately.
Anwyay, those who are interested can read the reviewed document at
http://www.usenix.org/events/usenix99/millert.html
and decide whether they want these functions or not.
(The above page is the abstract and there are URLs leading to PS and
PDF files of the full paper.
Come to think of it the inefficiency of strncpy due to null-filling
at the end is also mentioned in the paper.)
>Now, *excuuuse me*, but this seems *efficient* and *safe* to me! Not to
>mention mondo more elegant than (1) maintaining fragile string length
>invariants or (2) relatively cryptic one-liners like
>
>*((char *) mempcpy (dst, src, n)) = '\0';
Agreed.
This is why I think the strlcpy and friends can have
their own seats in the library.
Well documented library functions (presumably debugged better than
home-brewed varieties) help us in maintaining programs.
There is a phrase in the paper "make code auditing easier" aside from
simplifying the job of programmers, and I heartily agree.
--
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