Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.sys.apple
Subject: Re: Orca/C
Message-ID: <9916@smoke.BRL.MIL>
Date: 24 Mar 89 15:15:09 GMT
References: <806@orbit.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 58

In article <806@orbit.UUCP> dougm@pnet51.cts.com (Doug Mcintyre) writes:
>ANSI C uses \p for a pointer type in printf, and APW C uses \p in strings to
>represent pascal strings, so he went the APW C way.

I think what you mean is that APW C *printf() functions use the %p format
specifier for Pascal-style character strings (as opposed to native C null-
byte terminated char arrays).  ANSI C *printf() formats use %p for output
of a void* (canonicalized object pointer) in an "implementation-defined"
format that must be reversible (via *scanf() with %p) but otherwise is up
to the C implementor to specify.  I see little use other than in debugging
for ANSI C %p, so this particular deviation doesn't worry me too much, but
it does require that __STDC__ not be defined as 1, and that DOES worry me,
since that's generally how K&R1 vs. ANSI flavors of code are conditionally
selected for compilation.

How common ARE Pascal-style strings in APW C *printf() invocations?  If as
I suspect they are exceedingly rare, then it makes no sense to lose ANSI C
standard conformance for this one point.  A change to %P would be a trivial
way to continue to provide support for Pascal-style strings.  It even fits
better the convention of using upper-case flags for local inventions and
leaving the lower-case ones for expansion of standard things.  (As in UNIX
command-line option arguments.)

One exceedingly simple way to have this both ways is for the printf()
internal implementation to be testing not for 'p' or 'P' but rather for
whatever is stored in a global variable, preinitialized whatever way
ByteWorks prefers.  Then the run-time startoff code can be tweaked to
substitute the other character constant if the other interpretation is
desired.

>I don't quite understand about adding keywords. Pascal is a pretty valid
>keyword (I believe it is also used in the IBM compilers with another
>meaning..) so from the above paragraph Orca/C will still have the APW C
>meaning of pascal..

"pascal" is not allowed to be usurped for use as a keyword by an ANSI C
conforming implementation.  One of the major purposes of the standard is
to squelch exactly this sort of runaway invention of reserved names that
can be used by the application in some environments but will cause the
application to break miserably when ported into another (APW C, for
example).  Standard-conforming C implementations ARE allowed to reserve
names for their own use, but they must start with an underscore (the
exact rule depends on which name space is involved).  Applications ported
from other environments will be unaffected by the "special" meaning that
names such as "__pascal" suddenly acquire in the APW C environment,
because they will avoid using such names; there is no way, on the other
hand, that a C programmer could have anticipated that some implementation
would have assigned a special meaning to "pascal", which is a fairly
likely name for some program variable.

>What is the difference between #if and #ifdef if the symbol defined as 1
>or 0? APW C seems to think there is a difference sometimes and wont
>compile #if SYMBOL, but does just fine with #ifdef SYMBOL.

Well, maybe it's doing the right thing.  #if SYMBOL takes the true branch
if SYMBOL is defined as 1 but not if it is defined as 0 or if it is
undefined.  #ifdef SYMBOL takes the true branch for either 1 or 0 but not
if SYMBOL is undefined.  Thus there is a difference.