Re: VMS

On Sun, 22 Jun 2025 13:50:03 -0000 (UTC), candycanearter07 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?

No, malloc is N bytes.  calloc is N elements of sizeof(foo).  Also
malloc() doesn't initialize the memory but calloc() zeroes it out. That
can be another pitfall if you're using something like memcpy() with
strings and don't copy in the terminating NUL.  If you try something like
printf("%s", my_string) if you're really lucky there will have been a NUL
in the garbage; if not the string will be terminated somewhere, maybe.

calloc() is to be preferred imnsho. In many cases you're going to memset()
the malloc'd memory to 0 so you might as well get it over with.