Re: VMS

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