Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Riches <spamtrap42@jacob21819.net>
Newsgroups: comp.os.linux.misc
Subject: Re: VMS
Date: 25 Jun 2025 03:01:33 GMT
Organization: none-at-all
Lines: 43
Message-ID: <slrn105mpkd.q0k.spamtrap42@one.localnet>
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>
Reply-To: spamtrap42@jacob21819.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net BeuV4cldJ0TBLbSzDW0XBQyz+eXjOlU5t0bHPx1p4/40WcApkH
Cancel-Lock: sha1:RR3wBDv2uoSU60icf0gcm2Eniog= sha256:MhsEuEYzAaVJohoPmj91USAeOhvOqq0aRKGH7FS13N4=
User-Agent: slrn/1.0.3 (Linux)

On 2025-06-24, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Robert Riches <spamtrap42@jacob21819.net> writes:
>> On 2025-06-22, candycanearter07
>> <candycanearter07@candycanearter07.nomail.afraid> wrote:
>>> 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.
>
> Yes. char is the unit in which sizeof measures things. Multiplying by
> ‘sizeof (char)’ is a completely incoherent thing to do.
>
> And as noted elsewhere, doing the multiplication yourself is generally
> the wrong approach.
>
>> IIUC, heap-based malloc _usually_ returns a larger allocation
>> block than you really asked for.
>
> Yes.
>
>> 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.
>
> This is wrong. Exceeding the space allocated by even 1 byte is undefined
> behavior, even if the allocation happens to have been sufficiently
> padded. What this means in practice is very situational but
> optimizations exploiting the freedom that undefined behavior provides to
> the compiler routinely result in defects.

Please remember that this was an unintended _BUG_ in some old
code, _NOT_ a deliberately chosen strategy.  What I was
describing was one possible explanation for how the bug remained
undetected for some number of years.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)