Paul Eggert <eggerttwinsun.com> writes:

> I sense that your intuition tells you that adding strlcpy/strlcat to
> glibc will lessen the overall work required for the GNU project. My
> intuition tells me just the opposite.

I could see a case being made that it would make almost no
difference. But how does it make it harder?

Consider: if it isn't in glibc, it basically has to get added to
autoconf. One way or the other, the function is going to be part of
the GNU Project, and it's going to have to be maintained.

Moreover, it seems really clear to me that making autoconf the
fallback library for the functions that could be in glibc but aren't
results in making those functions that much harder to maintain well.
One case of this is the optimization issue I mentioned earlier, but
more to the point: whatever maintenance cost you see as being imposed
by adding the function to glibc will be necessarily borne by autoconf,
and in a way that is much more brittle and imposes much more hassle on
all the related developers.

Thomas

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]