Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc,alt.folklore.computers,alt.unix.geeks
Subject: Re: What is wrong with C? (and fond memories of VAX)
Date: 7 Jan 2026 01:40:29 GMT
Lines: 33
Message-ID: <ms5rsdFu9dvU1@mid.individual.net>
References: <CtydnVqzjrtfd5P0nZ2dnZfqn_adnZ2d@giganews.com> <10jduat$22c54$1@dont-email.me> <rnz6R.1239136$79B9.26533@fx14.iad> <10jelfq$2apo7$4@dont-email.me> <l8-cneav0pWdncb0nZ2dnZfqnPqdnZ2d@giganews.com> <8pI6R.1243340$79B9.1051909@fx14.iad> <ms2brmFbv84U2@mid.individual.net> <10jguou$341pn$1@nntp.eternal-september.org> <27cv2mx5fl.ln2@Telcontar.valinor> <slrn10lq9p0.32pp5.lars@cleo.beagle-ears.com> <4Wc7R.1392895$ACS3.688415@fx17.iad> <ms58ihFqgiaU7@mid.individual.net> <uBf7R.805816$i%aa.766425@fx12.iad> <wwva4yqz719.fsf@LkoBDZeT.terraraq.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net pttlz9wrvJLFmExHIxRUIgRx5MFx9JGMR5L6yuoJmsxly/OOB4
Cancel-Lock: sha1:rJvizVcfh6eqZMY5KeOCDL6EiNo= sha256:njWYdJ4iK0EfJUK07uJ+LfiRN3tzTCd1E7v0DV3Ig8g=
User-Agent: Pan/0.162 (Pokrosvk)
Xref: csiph.com comp.os.linux.misc:80639 alt.folklore.computers:233302 alt.unix.geeks:170

On Tue, 06 Jan 2026 22:54:26 +0000, Richard Kettlewell wrote:

> scott@slp53.sl.home (Scott Lurndal) writes:
>> rbowman <bowman@montana.com> writes:
>>>On Tue, 06 Jan 2026 18:57:04 GMT, Charlie Gibbs wrote:
>>>> Inspired by readline(), I've written my own replacements for strcpy()
>>>> and strcat() that do much the same thing.
>>>
>>>To quote from the strcat man page "Read about Shlemiel the painter.".
>>>stpcpy() was a late arrival and I never used it. I do use a similar
>>>construct
>>>
>>>char buf[1024];
>>>char* ptr = buf;
>>>
>>>ptr += sprintf(ptr, "%s", "some stuff");
>>>ptr += sprintf(ptr, "%s", " some more stuff");
>>
>> I would suggest using snprintf instead of sprintf to prevent accesses
>> beyond (buf + 1024).  A bit more complicated if you want to know that
>> the result was truncated, since you need to adjust the remaining length
>> based on the return value from the prior snprintf, as well as checking
>> for overflow.
> 
> This is calling out for a wrapping up in a function or two that can do
> the book-keeping automatically (and use an expandable buffer, if the use
> case demands).



Ah, mission creep...