Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: Thoughts on moving towards ANSI
Message-ID: <9621@smoke.BRL.MIL>
Date: 8 Feb 89 19:49:36 GMT
References: <795@n8emr.UUCP>
Reply-To: Gwyn@BRL.MIL (Doug Gwyn (VLD/VMB))
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 44

In article <795@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes:
>His statement was that he was going to provide as much ANSI as possible, but
>that there were some points at which there would be problems, since the existing
>environment of C code for this machine (GS/Mac type environment) used a few
>special extensions that were incompatible with ANSI.  As an example, he mentioned
>that in APW C and I assume MPW C, a printf format of %p was used for 'pascal'
>format strings, where the length is specified as a 2 byte (?) value before
>the string.  Thus, he wasnt going to be able to support the ANSI %p for pointer
>format.

It rather defeats the purpose of a standard to ignore it whenever
it conflicts with a previous implementation!

In the case of %p, so-called "Pascal" strings could be supported
compatibly with the standard by using %P for them.  There is some
question which of: (Pascal strings, pointers) is least frequently
printed from C code, but no question at all what portable C code
will be using %p for.  (Fortunately this is a relatively
unimportant feature.)  A much better way to support Pascal string
printing would be to provide a pascal_to_c_string() function and
write such printf()s like
	printf( "string is \"%s\"\n", pascal_to_c_string( pasc_str ) );

Note also that the "pascal" keyword of APW C should be changed to
something like _pascal_ and then for compatibility the APW-specific
headers (NOT the ANSI-standard headers) could #define pascal _pascal_
just in case some old APW C code was using "pascal" directly instead
of just relying on the headers in 4/CINCLUDE.

>How will other vendors be handling the changing of such things - note that
>this isnt a compile time problem but a run time problem.  Will all other
>vendors in non-unix environments just force customers to go with the new
>standard, become semi-standard, or is there some standard ways someone can
>specify whether certain run time interpretations are to be made...

As a user of APW C, I definitely want the ANSI C Standard followed
to the letter, plus non-conflicting APW-specific extensions added.
I hope vendors don't try to cheat on standard conformance.  They
just make more, not less, work for me if they do.

If the vendor you're talking about (ByteWorks, perhaps?) wants to
have me Beta-test their APW C implementation, I'll be glad to give
them detailed feedback.  I did this for Manx's ProDOS version of
Aztec C.