bkahn@archive.rtp.dg.com (Bruce Kahn) (08/17/90)
Ok, Im back w/another C question. I have Orca/C 1.1b9 (the upgrade is 'in
the mail') and want to compile C written (and compiled) under APW C. If
I #include the file stdlib.h with Orca/C I get the error:
39: void *bsearch(void *key, void *base, size_t count, size_t size,
int (*compar) (const void *p1, const void *p2));
^ ) expected
Im assuming that since this is a standard include file that the routines
SHOULD be parsable by the compiler (silly me I know). Has anyone else ever
used stdlib.h with Orca/C and NOT had this problem??
Under the same token (no pun intended), will APW C allow you to, in an
include file, declare a variable as 'extern int Flag_A' and then within
the source code redeclare it as 'int Flag_A' w/o choking?? Is this 'legal'
by ANSI C definitions?
And finally (ok 4 questions) can anyone tell me the differences between
the APW C and Orca/C compilers (ie: APW C has string.h and Orca/C has
strings.h)?
Bruce (bkahn@archive.rtp.dg.com or
kahn@adam.dg.com)
Standard disclaimers apply, except where prohibited by law...jb10320@uxa.cso.uiuc.edu (Desdinova) (08/19/90)
In article <792@dg.dg.com> bkahn@archive.rtp.dg.com (Bruce Kahn) writes: > > Ok, Im back w/another C question. I have Orca/C 1.1b9 (the upgrade is 'in >the mail') and want to compile C written (and compiled) under APW C. If >I #include the file stdlib.h with Orca/C I get the error: > >39: void *bsearch(void *key, void *base, size_t count, size_t size, > int (*compar) (const void *p1, const void *p2)); > ^ ) expected > > Im assuming that since this is a standard include file that the routines >SHOULD be parsable by the compiler (silly me I know). Has anyone else ever >used stdlib.h with Orca/C and NOT had this problem?? I have not had this problem (with either 1.1b9 or 1.1 final release). You're not trying to compile the APW headers with ORCA, are you? I don't know what would cause that error, except that 1.1b9 is very very messed up. You might just wait for your upgrade. > Under the same token (no pun intended), will APW C allow you to, in an >include file, declare a variable as 'extern int Flag_A' and then within >the source code redeclare it as 'int Flag_A' w/o choking?? Is this 'legal' >by ANSI C definitions? Last I checked, APW didn't follow ANSI specs ('course the last APW I saw was 1.0b4, about a year and a half before they finished it). I know that ORCA follows ANSI (pretty much) and allows the above example. > And finally (ok 4 questions) can anyone tell me the differences between >the APW C and Orca/C compilers (ie: APW C has string.h and Orca/C has >strings.h)? Well, to start out wish, APW hasn't had the same code generation bug through two commercial releases (my main gripe with ORCA), but if you're at all interested in compiling Unix software on your GS then ORCA is definitely the way to go. It's more standardized than APW (again, I haven't seen an APW for over a year). ORCA is _FAST_. With a transwarp it would kill Turbo C on a 12MHz AT. (well, maybe not quite- I haven't run Turbo on my AT yet...) ORCA produces _SMALL_ code- small as they come on the 65816. Maybe someone can extol APW's virtues. Do I have any volunteers? (APW is definitely more bug-free, for one thing). > > Bruce (bkahn@archive.rtp.dg.com or > kahn@adam.dg.com) -- Jawaid Bazyar | This message was posted to thousands of machines Junior/Computer Engineering | throughout the entire civilized world. It cost jb10320@uxa.cso.uiuc.edu | the net hundreds, maybe thousands of dollars, | to send everywhere.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/19/90)
In article <792@dg.dg.com> bkahn@archive.rtp.dg.com (Bruce Kahn) writes: > Under the same token (no pun intended), will APW C allow you to, in an >include file, declare a variable as 'extern int Flag_A' and then within >the source code redeclare it as 'int Flag_A' w/o choking?? Is this 'legal' >by ANSI C definitions? Certainly, as I understand what you're describing, it is allowed. The only objects that cannot be declared multiple times are those having no linkage. You're describing objects with external linkage. > And finally (ok 4 questions) can anyone tell me the differences between >the APW C and Orca/C compilers (ie: APW C has string.h and Orca/C has >strings.h)? ORCA/C has <string.h>, which is the standard header associated with the str*() functions. <strings.h> is a Berkeleyism that originated with a misunderstood description of the <string.h> header that AT&T was providing; more recent releases of BSD have contained <string.h> (also <strings.h>, just because some BSD-specific applications were now committed to using it). The main differences are (1) ORCA/C is supported; APW C is not. (2) ORCA/C attempts to conform to the C standard; APW C implements one interpretation of an old nonstandard UNIX flavor of C. (3) ORCA/C has a much better debugging environment.
bkahn@dg-rtp.dg.com (Bruce Kahn) (08/20/90)
In article <13615@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: |> In article <792@dg.dg.com> bkahn@archive.rtp.dg.com (Bruce Kahn) writes: |> > Under the same token (no pun intended), will APW C allow you to, in an |> >include file, declare a variable as 'extern int Flag_A' and then within |> >the source code redeclare it as 'int Flag_A' w/o choking?? Is this 'legal' |> >by ANSI C definitions? |> |> Certainly, as I understand what you're describing, it is allowed. |> The only objects that cannot be declared multiple times are those |> having no linkage. You're describing objects with external linkage. |> Finally got ahold of Mike and he told me that 1.1b9 does NOT do this and that this bug has been fixed in the final release. The 'final release' is being 'bundled now' but he didnt give a shipping date for when they will be sent out to users. Sure hope it comes soon as I dont plan on hacking my code to work just because of this... I think my problem using stdlib.h was due to the fact that I overwrote my Orca/C include file with my APW Tools & APW C include files. Time to sort out my include trees... -- Bruce (bkahn@archive.rtp.dg.com or kahn@adam.dg.com) Standard disclaimers apply, except where prohibited by law...