Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!usc!ginosko!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Strings in C (Re: ambiguous ?)
Message-ID: <11423@smoke.BRL.MIL>
Date: 27 Oct 89 17:48:13 GMT
References: <11398@smoke.BRL.MIL> <14115@lanl.gov> <2522@munnari.oz.au> <6676@ficc.uu.net>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <6676@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In most Macintosh C compilers that I've seen, the syntax !"%p...."! is
>used to indicate byte-counted strings. P stands for "pascal".
>Was X3J11 aware of this? Or are the Mac compiler vendors going to change?

Yes, at least some of us were quite aware of this.  There are also other
nonstandard vendor extensions to fprintf() format specs in existence.
I've argued numerous times with C implementors that using %p for "Pascal"
(counted) strings encouraged non-portable programming.  Unfortunately
Apple's ToolBox interfaces are designed for Pascal, not C; the same malady
later showed up on the Apple IIGS.  There are better solutions, though,
such as providing Pascal-to-C string translator functions in the C library.
Note that ByteWorks' ORCA/C for the Apple IIGS will remain non-compliant
with the C Standard unless Mike Westerfield reverses his decision about
this.  (ORCA/C does provide conversion functions, so %p=>Pascal is not
really necessary.)

I have no idea whether or not the Mac compilers will ever become Standard
conforming.  From what I hear, most of them come nowhere close to
providing a full hosted implementation.