Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Speaking of ksh
Message-ID: <8015@brl-smoke.ARPA>
Date: 4 Jun 88 22:02:19 GMT
References: <300@hi3.aca.mcc.com.UUCP> <3870001@hpcuhb.HP.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

nKeywords:

In article <3870001@hpcuhb.HP.COM> kluft@hpcuhb.HP.COM (Ian Kluft) writes:
>I've seen malloc() bomb many times on an AT&T 3B5 at CSU Chico when people
>used char [] and char * interchangeably across function calls.  These have
>been considered equivalent in all the C texts way back to K&R but, in reality,
>at least AT&T's C compiler cannot always swallow it.

Wait a doggone minute.  An array has NEVER been equivalent to a pointer.
The NAME of an array, when used in an expression, is (in MOST cases, but
not all) converted to a pointer to its initial member.

A FORMAL PARAMETER in a function definition written as char foo[]
is taken to be char *foo.  I have never seen an AT&T C compiler have
trouble with this, and I've seen a lot of AT&T C compilers.

>Why it affects malloc() we never exactly figured out.  But this has always
>fixed problems that sounded identical to what you just described.

If someone passed the address of a statically-allocated array to free(),
it could certainly cause a later malloc() to run amok.