Re: PATCH: safe string copy and concetation

[Chiaki Ishikawa <Chiaki dot Ishikawa at personal-media dot co dot jp>]

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