Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.misc
Subject: Re: VMS
Date: 22 Jun 2025 19:23:02 GMT
Lines: 45
Message-ID: <mbr3glF5ijfU3@mid.individual.net>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net kyK0fXUQWKk4he+L56vyfgqgymUG31N6VVEmUAfkYFcu8duQOH
Cancel-Lock: sha1:b2OeW0Ec8a98JXbm8bAfWjjUEJ0= sha256:LdInDjmpFcPEyL3zbLy1WAsT2FvuWCVPleUepZKqq/I=
User-Agent: Pan/0.160 (Toresk; )

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.