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.