This is the mail archive of the
mailing list for the glibc project.
Re: [open-source] Re: Wish for 2002
- From: David Wagner <daw at cs dot berkeley dot edu>
- To: eggert at twinsun dot com
- Cc: dwheeler at ida dot org, leclerc at austin dot sns dot slb dot com, libc-alpha at sources dot redhat dot com, open-source at csl dot sri dot com
- Date: Fri, 4 Jan 2002 14:16:37 -0800 (PST)
- Subject: Re: [open-source] Re: Wish for 2002
> 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.