This is the mail archive of the 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]
Other format: [Raw text]

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

On Jan 11, 2002, Valentin Nechayev <> wrote:

> requires programmer to keep real buffer size in sight.

That's the error in the approach.  As written before, the GNU project
recommends programs to avoid arbitrary limitations such as fixed-size
buffers.  So strlcat/cpy are contrary to the GNU way.

> Unless C were muted to support reliable strings, at least similar to
> C++ std::string class, programmers will use dangerous strcpy/strcat
> stuff and make errors in this use.

If that's what programmers will use, what's the point of adding
strlcpy/cat? :-P :-D

> that matters it helps against bugs

Against buffer overflow bugs, no more.  And it will help introduce
another class of bugs that fixed-size buffers will never be able to

One approach I like very much is that of stralloc, that I first saw in
Amanda code.  Concatenating multiple strings into a newly-allocated
buffer created with the right size is as simple as stralloc(string1,
string2, ..., NULL);

It's an unfortunate thing that, if the NULL is left out, you'll not
get a hard error at compile time, and if the chunk of code isn't
exercised very often, you may end up with an exploitable run-time
crash.  I still find this better than being connected to instead of just because the
implementor chose a 24-byte buffer and used strlcat to concat
"http://"; to the FQDN host name.

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

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