Path: utzoo!attcan!uunet!lll-winken!xanth!ames!sun-barr!texsun!texbell!sugar!ficc!karl
From: karl@ficc.uu.net (karl lehenbauer)
Newsgroups: comp.sys.intel
Subject: Re: PLM vs. C for 80286/80386
Keywords: PLM C
Message-ID: <4454@ficc.uu.net>
Date: 8 Jun 89 12:55:11 GMT
References: <598@philtis.UUCP> <126@tridom.uucp>
Organization: Ferranti International Controls
Lines: 22

In article <126@tridom.uucp>, wht@tridom.uucp (Warren Tucker) writes:
> 5.  PL/M is inherently a strongly typed language.  It is
> very hard to screw up the number and type of parameters
> supplied to a function, etc.  This might be a good thing for
> what you are trying to accomplish.  Passing a variable
> number of arguments to some function like printf is nice,
> but having the facility all over the language is why
> function prototyping and lint were invented.

True enough, but as I was just commenting over in comp.realtime where we've
been discussing this as well, unlike in C, PL/M pointers don't have data
types beyond being pointers.  (now quoting from <4423@ficc.uu.net>)

Thus, a lot of improper use of pointers which would cause warnings (at
least) from most C compilers are passed without comment by PL/M and one gets
to find the problem by debugging.  We do a lot of stuff that has to be
FORTRAN-callable, and *all* the parameters for a PL/M routine that's FORTRAN-
callable have to be pointers, so a lot of the benefits of data type checking
by the compiler are lost to us.
-- 
-- uunet!ficc!karl	"Contemptuous lights flashed across the computer's
-- karl@ficc.uu.net	 console."  -- Hitchhiker's Guide