Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Even more on MPW C 3.0 question
Message-ID: <10376@hoptoad.uucp>
Date: 21 Feb 90 02:13:16 GMT
References: <162.25dfe4b3@waikato.ac.nz> <10311@hoptoad.uucp> <167.25e15b52@waikato.ac.nz>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 22

In article <167.25e15b52@waikato.ac.nz> ccc_ldo@waikato.ac.nz writes:
>In <10311@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) says that
>(Str255 *) is a "nonsense" type. Perhaps this is true. I'm ready
>to give up trying to find a better answer.

Actually, John Gilmore, who follows the C standard, informs me that
pointers to arrays have always been legal; the problem has been that
the address operator had previously been defined as a no-op on arrays,
where it should have given a value of the type pointer-to-array.  The
ANSI C standard fixes this so &array does produce pointer-to-array, and
MPW C would appear to be noncompliant in this respect, since it uses
the old no-op interpretation.  If this is correct, your original code
should have worked, and it only failed because of a non-compliance to
the ANSI standard in MPW C.

However, you can still avoid all these issues completely using the
StringPtr solution I suggested.  No funny type casts, either.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Every institution I've ever been associated with has tried to screw me."
	-- Stephen Wolfram