Path: nntp.eternal-september.org!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: Fri, 27 Jun 2025 06:00:03 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 68
Message-ID: <slrn105sci1.1ibsg.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>
 <slrn105g20l.3q8n7.candycanearter07@candydeb.host.invalid>
 <slrn105k75h.h13.spamtrap42@one.localnet>
Injection-Date: Fri, 27 Jun 2025 08:00:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e6abfc5fd2284da38de1ded8e9eabd2d";
	logging-data="4186620"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/1INw+puGtpAGj8uuv/6nnD7XCue3O8hYY2EBQ/zgR4w=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:E0hLC5zMrE67ObHX9rP7JpRgx1c=
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:34 this Tuesday (GMT):
> On 2025-06-22, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
>> 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?
>
> Multiply by sizeof what?  sizeof(char)?  This was in the
> pre-Unicode days.  Even now with Unicode, IIUC sizeof(char) is
> still always 1.

I still multiply by sizeof(char), half because of habit and half to make
it clear to myself I'm making a char array, even if its "redundant". I
kinda thought that was the "cannonical" way to do that, since you could
have a weird edge case with a system defining char as something else?

>>> 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...
>
> IIUC, heap-based malloc _usually_ returns a larger allocation
> block than you really asked for.  As long as malloc gave you at
> least 2 extra bytes, you'd never see any misbehavior.  Even if it
> didn't give you 2 or more extra bytes, it's fairly likely you'd
> just get lucky and never see the program crash or otherwise
> misbehavior in a significant way.  For example, if you stomped on
> the header of the next allocation block, as long as nothing ever
> read and acted upon the data in said header, you'd never see it.


Oh, so it was some poorly written code being covered up by a weird quirk
in the 32b version of the compiler? Always interesting hearing about
"accidentilly working" programs.
-- 
user <candycane> is generated from /dev/urandom