This is the mail archive of the libc-alpha@sources.redhat.com 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 Sat, Jan 12, 2002 at 10:32:19AM +0200, Valentin Nechayev wrote:
> Come to sinful land from your elephant bone towers. Your glibc isn't written
> for you yourselves, or for another gurus; it is written for all.

And that's the whole point. If there are a lot of people who think
strlc*() is better and want to use it, IMHO glibc  should provide them
(maybe with a warning). It doesn't matter if you like them or not,
other people like them and you should respect their opinion. 

> > I've examined only their first use (where strlcpy is used
> > in a questionable way, and for all I know could be exploited by an
> > attacker), and on their first use that is not questionable (where the
> > strlcat calls are technically inferior to the standard alternatives).
> > However, my brief impression from briefly looking at the "egrep"
> > output is that these two examples are typical.  If so, OpenSSH
> > provides evidence against the use of strlcpy/strlcat.
> 
> They are hardly nesessary in openssh. They are useful most elsewhere.

The problem is that every function can be abused and you can make ugly
code with every function. That's no reason for not including that
function in glibc.

> > > 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.
> 
> Not all buffers are required to be of arbitrary size even with this approach.
> Not all buffers are allowed to be of arbitrary size even with this approach.
> Consider, e.g., buffer of outgoing NNTP command. One must not make
> such command longer than 512 bytes, including terminating "\r\n".
> There is no need to allocate million-byte string for NNTP command only
> to check that it is too long; buffer of fixed size works here better.
> Similarly, one must not overflow 1024-bytes path buffer, unless special
> approach to reach longer path is used, as libtwonyeight implements.
> There are many such examples.

That 1024-byte path buffer is stupid and unportable. First why do you
use a 1024-byte long buffer when the path is probably only 100 bytes
long? That looks like a waste of resource to me, dynamic allocation is
better.

Second using a fixed-length buffer is wrong and hardcoding it to use
1024 bytes is even more wrong. There are systems which don't have a
limit on the path, the GNU system for example, because having a limit
isn't required by POSIX and limits are just bad things (and in the
Hurd I can easily think about paths longer than 1024 bytes).

> And even when the case is ready for such GNU recommendation, not all programs
> are of GNU. Unless you are Richard Stallman or his fanatical follower,
> you don't consider glibc as environment only for GNU software.

I can't speak for him, but I think even Richard Stallman doesn't
consider glibc only for GNU software (else it was probably GPL'd and
not LGPL'd).
 
Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

Attachment: msg00168/pgp00000.pgp
Description: PGP signature


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