Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc
Subject: Re: VMS
Date: 25 Jun 2025 06:52:19 GMT
Lines: 26
Message-ID: <mc1kl2F95ocU1@mid.individual.net>
References: <wCqdnYde9MIbmND1nZ2dnZfqnPadnZ2d@giganews.com> <87tt4i9nw5.fsf@eder.anydns.info> <102l0h9$fjtb$5@dont-email.me> <Z2udned3u9ZgqtP1nZ2dnZfqnPudnZ2d@giganews.com> <slrn1054j9c.3ce8.candycanearter07@candydeb.host.invalid> <PpudnVnCnvuYxc_1nZ2dnZfqnPudnZ2d@giganews.com> <wwva564xjps.fsf@LkoBDZeT.terraraq.uk> <4_GdncCsf-Nqe8n1nZ2dnZfqnPSdnZ2d@giganews.com> <wwv5xgqkfl9.fsf@LkoBDZeT.terraraq.uk> <103392c$lpbg$5@dont-email.me> <1033o4a$1qj6$3@dont-email.me> <1033tv1$3aqu$3@dont-email.me> <1034pj8$a74s$1@dont-email.me> <mbmm2nFdsgcU2@mid.individual.net> <slrn105cajs.4vj.spamtrap42@one.localnet> <slrn105g20l.3q8n7.candycanearter07@candydeb.host.invalid> <slrn105k75h.h13.spamtrap42@one.localnet> <wwvpletmv3e.fsf@LkoBDZeT.terraraq.uk> <slrn105mpkd.q0k.spamtrap42@one.localnet> <KeednUgPwP3EDcb1nZ2dnZfqn_QAAAAA@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net cfsab43MTl36hAxnSOtVbQhWpe9sMFJqR4iGjV1kg0PNU3Q7js
Cancel-Lock: sha1:Y1opU3SV5OvDSfqCTF7ZHbJBtLM= sha256:hrmZckE5Sa1h+9Lrrd0nKSncixJMEeYSxSGcLcH6oXc=
User-Agent: Pan/0.160 (Toresk; )
Xref: csiph.com comp.os.linux.misc:69115

On Wed, 25 Jun 2025 01:59:53 -0400, c186282 wrote:

>    Regardless, easy fix - always allocate at least one
>    byte/word/whatever more than you THINK you need. Minimal penalty -
>    possibly BIG gains.

I tend to think in powers of 2.

	char deviceId[64];
	char incidentNumber[32];
	char finalDisp[32];
	char comment[512];

Those are generous.  A typical incident number is 062525-1000.  Then I 
follow up with 

	fgets(incidentNumber, sizeof(incidentNumber)-1, stdin);

incidentNumber has been memset to 0 so even if the user gets carried away 
it will get truncated with a NUL. Some of the legacy code was stingy like 
they had to pay for every byte. That's the sort of thinking that leads to 
a 2038 problem way down the road. To be fair, nobody expected the code to 
be merrily chugging along 30 years later.