Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.os.linux.misc
Subject: Re: VMS
Date: Sun, 22 Jun 2025 13:50:03 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 43
Message-ID: <slrn105g20l.3q8n7.candycanearter07@candydeb.host.invalid>
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>
Injection-Date: Sun, 22 Jun 2025 15:50:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0c20ac70085e5a9785361077b427e278";
	logging-data="600466"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX196n4fTixZeDxic5SnL1482FjpeWkv3xY2qOubDUupShA=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:pESTl2ybS0sOdabr5RKgW2SC6Mk=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D

Robert Riches <spamtrap42@jacob21819.net> wrote at 03:43 this Saturday (GMT):
> On 2025-06-21, rbowman <bowman@montana.com> wrote:
>> On Fri, 20 Jun 2025 23:07:20 -0000 (UTC), Rich wrote:
>>
>>> Very likely, but the idea was to protect the typical programmer from
>>> their own common mistakes (of not carefully checking error return codes
>>> or buffer lengths, etc.).  I.e. the typical 9-5 contract programmer, not
>>> the Dennis Ritchie's of the world.
>>
>> I'm paranoid enough that I check the return of malloc and try to log the 
>> problem even though I'm probably screwed at that point. It has pointed out 
>> errors for calloc if you've manged to come up with a negative size.
>>
>> I have worked with programmers that assumed nothing bad would ever happen. 
>> Sadly, some had years of experience.
>
> Some years ago, I heard of a bug related to use of malloc.  The
> code had _intended_ to dynamically allocate storage for a string
> and the terminating null byte.  It was _intended_ to do this:
>
>         dest = malloc(strlen(src)+1);
>
> Instead, a paren was misplaced:
>
>         dest = malloc(strlen(src))+1;
>
> IIUC, the next line copied the src string into the newly-
> allocated destination.

Aren't you supposed to multiply by sizeof as well?

> Those who had worked on that project longer said the bug had been
> latent in the code for several years, most likely with alignment
> padding masking the bug from being discovered.  Curiously, the
> bug made itself manifest immediately upon changing from a 32-bit
> build environment to a 64-bit build environment.


I'm more surprised it didn't segfault. Any idea what caused it to not?
I know strlen doesn't account for the terminating character, but it
seems like it should've been TWO bytes shorter...
-- 
user <candycane> is generated from /dev/urandom