Path: ...!3.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: rbowman <bowman@montana.com>
Newsgroups: comp.os.linux.advocacy
Subject: Re: More Funny Stuff From Joel
Date: 15 Jun 2024 02:33:58 GMT
Lines: 68
Message-ID: <ld4cslFnt9iU1@mid.individual.net>
References: <17d716103c089ab3$7951$675878$802601b3@news.usenetexpress.com>
	<ej496jd0tb59u2l0nqtghq3u9ahhmann3s@4ax.com>
	<lcjnnuF896hU5@mid.individual.net>
	<kma96j1no1tp926ctejldkdk2c19aeruft@4ax.com>
	<lcjvk1F9n7aU1@mid.individual.net>
	<2ej96j1mbvgiok4q5c57vdlo94itpfu5dt@4ax.com>
	<6664e989$0$2363151$882e4bbb@reader.netnews.com>
	<slrnv6f9fl.2hg.candycanearter07@candydeb.host.invalid>
	<66687931$0$3747328$882e4bbb@reader.netnews.com>
	<slrnv6ig9v.13pi.candycanearter07@candydeb.host.invalid>
	<66699f8c$0$966$882e4bbb@reader.netnews.com>
	<slrnv6l2vk.24pu.candycanearter07@candydeb.host.invalid>
	<666b0963$0$985$882e4bbb@reader.netnews.com>
	<ld0olnF7p22U1@mid.individual.net>
	<666b43c2$0$966$882e4bbb@reader.netnews.com>
	<ld19dnFa6idU1@mid.individual.net>
	<666c4979$0$2363133$882e4bbb@reader.netnews.com>
	<ld3affFja99U1@mid.individual.net>
	<666c8888$0$7063$882e4bbb@reader.netnews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net /8ru+c61Pm34ZgOBQ34z9AMcGfXFZANffZbXjknK7FupgXMphx
Cancel-Lock: sha1:n6xRNT96YJA6VLmxjrQ+NFBeK3M= sha256:MydFLPr0JNY0q0Ocfgy9MHnfvPttliEHiDRAsF2e5dI=
User-Agent: Pan/0.149 (Bellevue; 4c157ba)
Bytes: 4083

On Fri, 14 Jun 2024 14:14:33 -0400, DFS wrote:


> Yep.  In the big stats program I posted I messed around with using a
> malloced array of 20,000.  It ran a bunch of times just fine, but all of
> a sudden I got nonsense results.
> 
> So I filled it with 0s before using it, and no problem.
> 
> But calloc saves a line of code, so that's what I used.

Yeah, that's the joy of undefined behavior.  In the original program with 
'int mode' not initialized it segfaulted pretty reliably on 
'md_count[mode]' if 'mode' happened to be a  garbage number. It *might* 
have been 0 for a dew runs.  'double mean' was uninitialized but on a few 
runs it was 0.0. Maybe the compiler was feeling nice but I wouldn't bet on 
it. If it wasn't 0.0, 'mean += nums[len];' wouldn't blow up but it would 
be bogus.

'int md_count[COUNT_CNT];' was another uninitialized one. I printed it out 
and some elements were 0, some were bogus which wiped out the mode logic 
even with mode initialized. 

Luckily, it did have 10 elements although the 0th would never be used. If 
it were md_count[COUNT_CNT-1] it could potentially get interesting. It's 
on the stack so md_count[9] possibly could corrupt something else on the 
stack like 'len'. That's a real crap shoot that depends on how the stack 
frame was built and what is adjacent. 

 
> On geeksforgeeks a calloc() example is:
> 
>    int* ptr;
>    ptr = (int*)calloc(n, sizeof(int));
> 
> Isn't the 2nd int* redundant?

Most C compilers let it slide but malloc, calloc, and realloc return void 
pointers.  C++ doesn't.

$ g++  -o mean mean.c
mean.c: In function ‘int main()’:
mean.c:15:21: error: invalid conversion from ‘void*’ to ‘int*’ [-
fpermissive]
   15 |         ptr = calloc(COUNT_CNT, sizeof(int));
      |               ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
      |                     |
      |                     void*


If you work with both languages and/or different compilers you get into 
the habit of explicitly casting the return. A C++ purist would frown on 
using calloc or malloc although you certainly can. 'new' probably uses one 
or the other under the hood but you don't want to mix and match free and 
delete.

Going the other way C++ allowed variable declarations outside of blocks. C 
finally caught up, I forget which version, but I would follow the C rule 
in C++ although I really prefer declaring a variable close to where you're 
going to use it.