Subject: Re: CVS commit: basesrc
To: None <email@example.com>
From: Alistair G. Crooks <firstname.lastname@example.org>
Date: 12/09/1999 00:54:03
> Hubert Feyrer writes:
> > - Only use strlcpy() on systems that have it, i.e. >=1.4K. This makes
> > this working again on 1.4 systems.
> i don't think that your `fix' is really that acceptable. the obvious
> workaround for earlier systems using code from -current is to supply
> the missing functions from libc (e.g, strlcpy()) and compile them into
> your 1.4 source.
> if we used this workaround for other user programs we'd want to use in
> earlier releases we'd end up with a horrible unmaintainable mess of
> spaghetti #ifdefs...
> please revert this change, and on your 1.4 systems where you need this
> program just drop in libc/string/strlcpy.c (possibly with the
> appropriate change to <string.h>).
And I, for one, think that causing changes to be made to header
files like <string.h>, causing separate files to be linked in,
conditionally, depending on version of NetBSD, because you object
to a 6-line C function duplicating recent libc functionality, and
which was gratuitously ripped out without asking, is complete
Please try to remember that this particular utility is designed to
be run on all versions of NetBSD, not just -current. It was also
designed, from the start, to be incorporated as a package (note
its ancestry). No, I'm not being a Luddite, just practical.
It's often the case that things in usr.sbin/user are done that way
for a good reason - if you're in any doubt, please don't hesitate
to ask, and I'll attempt to explain.
I'd prefer it if strnncpy() remained, just for just now, until
we're all happily running strlcpy(3)-enabled libc's.