Re: [libc-alpha] Re: Wish for 2002

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Thu, 3 Jan 2002, Christoph Hellwig wrote:

> Date: Thu, 3 Jan 2002 10:36:24 +0100
> From: Christoph Hellwig <hch@ns.caldera.de>
> To: Paul Eggert <eggert@twinsun.com>
> Cc: libc-alpha@sources.redhat.com,
>      Francois Leclerc <leclerc@austin.sns.slb.com>
> Subject: [libc-alpha] Re: Wish for 2002
> 
> In article <200201030059.g030xT301198@shade.twinsun.com> you wrote:
> > Portable code must define its own strlcat and strlcpy anyway, as these
> > functions are not standardized and have different semantics on
> > different hosts.
> 
> Please tell me which systems have different semantics than the
> strlcat/strlcpy versions described in Tod's USENIX paper?

Why are people pushing to have nonstandard crap in glibc?

These functions are not a solution to anything, except maybe a stopgap
fix for a program that has buffer overflows.

Any programmer who is conscientious enough to actually worry about his or
her program having correct behavior should be concerned not only about
buffer overflows, but about the consequences of silently discarding the
suffix of a string.

Also note that the C99 language has introduced a function called snprintf,
which has been implemented in glibc for some time (though in 2.0.x its
return value had different semantics). This *standard* function can do the
job of strlcat and strlcpy.

Roughly, strlcpy can be done like this:

  snprintf(destination, limit, "%s", source);

In fact, this one can be done using the C90 sprintf function:

  sprintf(destination, "%.*s", (int) limit, source);

The strlcat operation can be done like this:

  snprintf(destination, limit, "%s%s", destination, source);

It's trivial to write macros or inline functions around these things.
So porting a program which relies on strlcpy() or strlcat() should
be a breeze.

This function is more flexible, because you can catenate more than two
strings, and the target can be some buffer that doesn't overlap one of
the parameters:

    if (snprintf(path, sizeof path, "%s/%s", directory, file) >= sizeof path) {
       /* oops, not enough space, do something. */
    }

Why should functions be added to glibc for the sake of programmers who
carelessly use nonportable functions, and who cannot figure out these
simple workarounds?

> There's a lot of stuf under __USE_BSD in glibc that's in no standard at
> all.  strlcpy/strlcat is in ~75% of the currently sold unix versions
> which makes it some kind of defacto standard.

According to this argument, it would be even better to be implementing
functions like CreateEvent and WaitForMultipleObjects. More computers
on the planet have these than strlcpy and strlcat, and they are
somewhat harder to implement in terms of existing functions than
strlcpy and strlcat.