| Deutsch English Français Italiano |
|
<mc1kl2F95ocU1@mid.individual.net> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!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; ) 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.