lwv@n8emr.UUCP (Larry W. Virden) (02/08/89)
I have been talking to a software publisher who is working on a new C compiler. 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. 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... -- Larry W. Virden 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 75046,606 (CIS) ; LVirden (ALPE) ; osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (INTERNET) The world's not inherited from our parents, but borrowed from our children.
barmar@think.COM (Barry Margolin) (02/08/89)
In article <795@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > 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. This can be handled simply by providing two implementations of printf, which can be selected at link time. Another possibility would be to require something like Unix's "-Dformat=APW_format" for programs being ported from the old version to the new version, where the APW_format function implements the old printf semantics. Or you could have a compiler option that specifies whether you want compatible or ANSI semantics (it could predefine a bunch of such macros). Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/09/89)
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.