Path: utzoo!attcan!uunet!husc6!spdcc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: char *strcat(), *strcpy(), *fgets();
Message-ID: <4773@haddock.ISC.COM>
Date: 27 Jun 88 18:09:23 GMT
References: <1309@ark.cs.vu.nl> <11580010@hpisod2.HP.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 24

In article <11580010@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:
>While it's clear that we can't change the return value of strcat() because
>of applications (such as the one above) that use it, there's nothing to
>prevent adding more useful functions:

Since this is comp.std.c, I'll redeclare your list in ANSI.

>    char *strecpy(char *, char *)
>    char *strecat(char *, char *)
>    size_t strlcpy(char *, char *)
>    size_t strlcat(char *, char *)

Actually, given a useful set of end-string functions (including the simplest
one, "char *strend(char *)"), I see no need for any of the "cat" functions.
Even the standard strcat(x,y) is just strcpy(strend(x),y), and if the
application was designed properly it probably already has the value of
strend(x) in hand.

As Doug has noted, "str*" is reserved to the implementation.  Thus, the vendor
is free to add any of these to  as an extension (and would still
have a conforming implementation).  I suppose many implementations will put
strdup() there.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint