Date: Sun, 31 Oct 1999 02:28:54 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: chris@calldei.com Cc: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <199910302228.CAA03773@tejblum.pp.ru> In-Reply-To: Your message of "Fri, 29 Oct 1999 15:13:17 CDT." <19991029151317.E535@holly.calldei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Costello wrote: > On Fri, Oct 29, 1999, Randell Jesup wrote: > > stpcpy() (the issue in this case) is something I've seen in > > compiler's C libraries since the late 80's/early 90's (if I remember > > correctly) Yes. > First it's stpcpy, then GNU getopt, then ... Yes. So what? You are suffering from the "NIH" disease. (BTW, stpcpy is not first and is not GNUism/Linuxism). > The bigger issue of Linux compatibility is essentially what > this is leading into. Currently the biggest users of stpcpy are > Linux applications. Frankly it's hard enough at this point to > deal with problems with the GNU getopt (awfully difficult to port > programs using GNU getopt without replicating the getopt() code > from glibc). At the same time, there are dozens of other Linux > compatibility issues. Putting all these new foreign library > calls into libc is not the solution unless we're interested in a > larger library. The argument "hardware is cheap" is not valid. I don't care about Linux compatibility. stpcpy() is an useful function, even if only little useful. There is no more reason to call it bloat than for asprintf(), or strsignal(), or even fts(), or strvis() or strlcpy(). GNU getopt has nothing to do with stpcpy() and cannot be a valid argument to not include stpcpy() in libc. Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910302228.CAA03773>