Re: VMS

On 6/24/25 11:01 PM, Robert Riches wrote:

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.

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