Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Processing Instruction
Message-ID: <433@haddock.UUCP>
Date: Fri, 10-Apr-87 18:58:12 EST
Article-I.D.: haddock.433
Posted: Fri Apr 10 18:58:12 1987
Date-Received: Sat, 11-Apr-87 18:53:22 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15304@amdcad.UUCP> <486@danews.ATT.COM>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Distribution: na
Organization: Interactive Systems, Boston
Lines: 27
Xref: utgpu comp.arch:827 comp.lang.c:1546

In article <486@danews.ATT.COM> lvc@danews.ATT.COM (Larry Cipriani) writes:
>In article <15317@amdcad.UUCP>, rpw3@amdcad.UUCP (Rob Warnock) writes:
>> I find myself doing:
>> 	char *p = &buf[0];
>> 	int n;
>> 	strcpy(p, "piece");		p += strlen(p);
>> 	strcpy(p, "another piece");	p += strlen(p);
>> 	sprintf(p, "format%d%s", args...); p+= strlen(p);
>> 	strcpy(p, "still another piece"); p += strlen(p);
>> 	etc...
>
>It seems to me that the code would be far more readable and faster
>if it were written as:   p = cat(p1, p2, ..., (char*)0);

Or, to better mimic the original semantics,  p = cat(buf, p1, ...) with no
malloc involved.  (Yeah, the malloc version is useful too; I've got one of my
own.)

However, this is only useful if each operation is a strcpy or strcat; it
doesn't work if there are intermixed one-char stores (*p++ = c) or more
complex stuff (the embedded sprintf in the original example).

Of course, one could always write the whole thing with sprintf, using "%s%s%s"
format instead of strcat(strcat(strcpy(...))), but sometimes it's better to
use the low-level stuff.

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