Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ucsd!orion.cf.uci.edu!paris.ics.uci.edu!nagel
From: nagel@paris.ics.uci.edu (Mark Nagel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC almost gets it right.
Message-ID: <683@paris.ICS.UCI.EDU>
Date: 8 Sep 88 15:23:46 GMT
References: <5077@fluke.COM> <490@poseidon.UUCP> <3873@polya.Stanford.EDU>
Reply-To: nagel@paris.ics.uci.edu (Mark Nagel)
Organization: University of California, Irvine - Dept of ICS
Lines: 26

In article <3873@polya.Stanford.EDU> kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes:
|In article <490@poseidon.UUCP> ech@poseidon.UUCP (Edward C Horvath) writes:
| 
|>What drives me NUTS about LSC prototyping... is the
|>SILENT coercion of (incorrect) arguments.  Example: you pass 0 for the space
|>parameter to NewWindow.  This is an error, folks, it needs to be NIL or NULL
|>or, in any case, a LONG zero.  LSC is happy to silently notice that
|>the value ought to be long, and indeed generates code to push a long zero.
|
|Well, K&R says that '0' casts correctly to any NIL type.  If you were using
|MPW, '0' would already be 32 bits.  Syntax correctness does not imply semantic
|correctness.

This is only true for pointer assignment in K&R, you still have to cast NULL
for function calls or anywhere else where the actual pointer type isn't
clear from context.  In fact, I think that prototype conversion is very
nice.  You don't have to worry about what you've cast your NULL to. 
Since the compiler has a prototype in scope, it knows what type the
NULL pointer should be because it has context always, just as in
assignnment.  I believe this was one of the big reasons for adding 
prototypes to C.  Now if Think would just add ANSI prototypes...

-- 
Mark Nagel
Department of Information and Computer Science, UC Irvine
nagel@ics.uci.edu             (ARPA)             When they ship styrofoam...
{sdcsvax|ucbvax}!ucivax!nagel (UUCP)             ...what do they pack it in?