dougm@pnet51.cts.com (Doug Mcintyre) (03/24/89)
Oh by the way APW C does support large Arrays just fine. Just be careful when
allocating anything over 64k, use lmalloc, not a couple calls to malloc..
Anyway, I don't really know what all ANSI C requires of its librarys but Mike
said that he left out a few things that were for multitasking, that wouldn't
do anything on the IIGS..
Orca/C is going to try to be 100% compatible with APW C and be about 99% ANSI
C. As of right now I think that the only thing Mike had to change is that 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 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..
All other special compiler stuff is handled with the #pragma processor
directive which ansi c fully supports. All cda, nda support is through #pragma
as well as memory model stuff. The default is the APW C style memory model.
Also there are some nice things used by #pragma to make programming easier.
95% of the people who use APW C is going to use Orca/C. It is much nicer. APW
C in my opinion is never going to get its bugs fixed. My most anoying one is
that sometimes it can't do preprocessor directives correctly.. 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. I don't know of any bugs in the compiler per se,
but the preprocessor and the library could stand vast improvements..
UUCP: {rosevax, crash}!orbit!pnet51!dougm Compuserve: 70611,2215
ARPA: crash!orbit!pnet51!dougm@nosc.mil ALPE: DougMac
INET: dougm@pnet51.cts.comlwv@n8emr.UUCP (Larry W. Virden) (03/24/89)
Actually, the p difference you are thinking about is that in the *printf family, %p means print out a pointer value in ANSI and means print out a pascal type string in APW C. I talked to Mike about this on ALPE and he didnt seem like he was TOO set in his ways here - if there was enough demand for this one he might figure out some way to permit both via some sort of option... -- 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.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/24/89)
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.
shawn@pnet51.cts.com (Shawn Stanley) (06/03/89)
I just got notification in the mail that ORCA/C is available... Byte Works is
apparently shipping in a couple weeks. It's supposed to compile to smaller
and faster executables than APW C does. The listed cost is $150.
I'm looking forward to getting this... it'll be nice to have a good C compiler
finally!
UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn
INET: shawn@pnet51.cts.combird@ihlpf.ATT.COM (Walters) (06/04/89)
From article <766@orbit.UUCP>, by shawn@pnet51.cts.com (Shawn Stanley): > I just got notification in the mail that ORCA/C is > available... Byte Works is apparently shipping in a couple > weeks. It's supposed to compile to smaller > and faster executables than APW C does. The listed cost is $150. > Keep in mind that Programs Plus sells it for approx $150/2 -- Joe Walters att!ihlpf!bird IHP 1F-240 (312) 713-5356
STEIN@UCONNVM.BITNET (Alan Stein) (08/06/89)
I'm having problems with either the p2cstr or strcpy functions in Orca/C. After getting back a Pascal type string stored in char pst[20], I've tried transferring it to a C type string, to be stored in char cst[20], with the code strcpy(cst,p2cstr(pst)); but the program hangs. Has anyone else had this problem? Alan H. Stein | stein@uconnvm.bitnet Department of Mathematics | stein%uconnvm.bitnet@mitvma.mit.edu University of Connecticut | ...psuvax1!UCONNVM.BITNET!STEIN 32 Hillside Avenue | Waterbury, CT 06710 | Compu$erve 71545,1500 (203) 757-1231 | GEnie ah.stein
dhom@cosmos.acs.calpoly.edu (David Hom) (08/21/89)
I just purchased ORCA/C installed it on my hard disk and started to get acquainted with the desktop environment (I previously owned ORCA/M). Everything ran fine. I compiled bullseye.cc. When running the debugger step and trace ran fine. When I set auto-go, the green dots appeared, but when stepping through the code, it still stepped line by line through the area I set for auto-go. Then I tried to set a breakpoint. The purple "X" appeared, but when tracing through the code, the run did not stop at the breakpoint. I tried this several times then tried it on the original disks shipped to me with the same results--markers came up correctly, but the functions did not work. Has anyone else had this problem with ORCA/C? Any help would be greatly appreciated. David dhom@cosmos.acs.calpoly.edu
dhom@cosmos.acs.calpoly.edu (David Hom) (08/22/89)
In article <13704@polyslo.CalPoly.EDU> I write: >step and trace ran fine. When I set auto-go, the green dots appeared, >but when stepping through the code, it still stepped line by line through >the area I set for auto-go. Then I tried to set a breakpoint. The purple >"X" appeared, but when tracing through the code, the run did not stop at >the breakpoint. > I got a couple email responses to this posting voicing the same problem. I call Byteworks today. They know about the problem and will be releasing a free update to registered owners of Orca/C (so send in your registration cards.) David dhom@cosmos.acs.calpoly.edu
bird@cbnewsd.ATT.COM (j.l.walters) (08/22/89)
From article <13704@polyslo.CalPoly.EDU>, by dhom@cosmos.acs.calpoly.edu (David Hom): > Has anyone else had this problem with ORCA/C? Any help would be greatly > appreciated. > I have and so has everyone else. The debugger has got bugs that are supposed to be fixed sometime around 9/1/89. If you are a registered owner they will send you upgraded disks free. -- Joe Walters att!ihlpf!bird IHP 1F-240 (312) 713-5356