Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
Newsgroups: comp.os.linux.misc
Subject: Re: VMS
Date: Mon, 23 Jun 2025 18:10:02 -0000 (UTC)
Organization: the-candyden-of-code
Lines: 55
Message-ID: <slrn105j5it.2nvl6.candycanearter07@candydeb.host.invalid>
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>
 <mbr3glF5ijfU3@mid.individual.net>
Injection-Date: Mon, 23 Jun 2025 20:10:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e35ed6b8dc9d5896dda7b0a70a84e4ab";
	logging-data="1506672"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18dq7ZylH8CiSKnC50BuAOXkT7XT9vVnNXmh6SoniQCEg=="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:OsTzCupAmjqFzlpguFno4zvSQ4U=
X-Face: b{dPmN&%4|lEo,wUO\"KLEOu5N_br(N2Yuc5/qcR5i>9-!^e\.Tw9?/m0}/~:UOM:Zf]%
 b+ V4R8q|QiU/R8\|G\WpC`-s?=)\fbtNc&=/a3a)r7xbRI]Vl)r<%PTriJ3pGpl_/B6!8pe\btzx
 `~R! r3.0#lHRE+^Gro0[cjsban'vZ#j7,?I/tHk{s=TFJ:H?~=]`O*~3ZX`qik`b:.gVIc-[$t/e
 ZrQsWJ >|l^I_[pbsIqwoz.WGA]<D

rbowman <bowman@montana.com> wrote at 19:23 this Sunday (GMT):
> 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.

Right, and since malloc uses byte counts, you have to multiply by
sizeof to get the proper amount to allocate.

> 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.


Fair, but some might find it redundant to set the memory to 0 and
immidietly write data over those null bytes.
-- 
user <candycane> is generated from /dev/urandom