Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: net.micro.mac
Subject: Re: Consulair's Mac C compiler
Message-ID: <327@vaxb.calgary.UUCP>
Date: Wed, 20-Aug-86 18:37:46 EDT
Article-I.D.: vaxb.327
Posted: Wed Aug 20 18:37:46 1986
Date-Received: Thu, 21-Aug-86 05:48:22 EDT
References: <605@ur-tut.UUCP>
Distribution: net
Organization: U. of Calgary, Calgary, Ab.
Lines: 33
Summary: That isn't a bug.

In article <605@ur-tut.UUCP>, timd@ur-tut.UUCP (Tim D'Ascoli) writes:

> 	I hope that this posting will help someone avoid the "extra" debug time 
> that i had to spend when i was using Consulair's Mac C compiler. 
> 	In The Bible (K & R) on page 94 the following quote can be found, 
> "In short, any array and index expression can be written as a pointer and 
> offset, and vice versa, even in the same statement.", 
> (5:3:6 -- chapter, verse, and paragraph). 
> 
> 	My problem came with the following code segment:
> 
> 	/* declared as a global variable */
> 	char	**inputBuffer;
> 
> 		/* and then subsequently referenced in another file */
> 		extern	char	*inputBuffer[];
> 
> 		/* the following variable was also declared in that file 
> 		** as a local 
> 		*/
> 		char	*inputArray;
> 
> 		/* and then de-referencing the global in that file */
> 		inputArray = *inputBuffer;

I wouldn't consider this a flaw in Consulair C. I would expect this code
to be broken on any C compiler. Your declaration char *inputBuffer[]; will
expect to link to an actual allocated array of pointers to characters,
not to a pointer to a pointer. This is just the way C is. K&R may have
explained it poorly, but that's not Consulair's fault.

   Radford Neal
   The University of Calgary