Re: [open-source] Re: Wish for 2002

[David Wagner <daw at cs dot berkeley dot edu>]

> GNU applications typically are developed under a different model, with
> a set of maintainers who understand the code fairly well, and who try
> to improve the code quality and functionality.  In that model, my
> experience is that strlcpy and strlcat tend to be distractions: they
> tend to make the code noticeably harder to maintain without adding
> much safety.  That is why I recommend against their use in GNU code.

Could you elaborate on how the strl*() functions make it harder to
maintain GNU code?  I had trouble seeing how they are any different from
other forms of safe buffer manipulation (e.g., strncpy()).

The main burden on the programmer is that one must pass buffer sizes
along with all buffers.  Once you do this bookkeeping, it seems to me
that most of the strategies for safe buffer manipulation become pretty
easy, whether you prefer strl*() or strncpy() or something else entirely.
On the other hand, if you don't do this bookkeeping, it seems very hard
to be sure that your code is secure against buffer overruns.

So I can't see why strl*() are any worse than other strategies of
defending against bounds violations.  What am I missing?  Can you
enlighten me?  Thanks in advance.