smv@apollo.HP.COM (Steve Valentine) (09/12/90)
Subject: Re: How ANSI is Apollo's cc 6.7 (SR 10.2) > I've run into the following constructs in Apollo's standard include files. > The documentation (and the tech rep) both claimed that Apollo's C compiler is > ANSI C. I don't believe any of our documentation claims that the 6.7 C compiler is ANSI conforming. The rep may have been referring to the 6.8 compiler (now in beta), or could have simply been wrong. To be a "conforming hosted implementation" of ANSI C you need not only a conforming compiler, but also a conforming preprocessor, include files and C library. At sr10.2, we had most of the first, and little or none of the other three. The 6.7 C compiler release notes go into all the gory details of which ANSI C features are supported and which aren't. Of all the missing features, the lack of a conforming ANSI C preprocessor has caused the most problems. I'm happy to be able to say that we have a "conforming hosted implementation" on the way out the door now. #define OFFICIAL_NEWS_MODE I'm told that it's OK to announce the following: Sr10.3 includes the conforming preprocessor, include files, and C library. It is expected to begin shipping to customers in October. (Yes, this year.) The cr1.0 compiler fills in the last blank, and should begin shipping around the end of the year. (cr1.0 is also known as cc 6.8.) #undef OFFICIAL_NEWS_MODE As the SR10.3 release notes will tell you, we don't recommend (read that "don't support") trying to use the new include files or preprocessor without the new compiler. They will also tell you that you can choose to install the ANSI C support, or choose not to. If you choose ANSI C, the include files specified by ANSI C, and /bin/cc will be overwritten with new ANSI conforming versions. In addition, you get a new CPP, new crt0.o files, and the include files that are new with ANSI C. The ANSI C include files are available in both bsd4.3 and sys5.3 environments. If you're an Aegis user interested in standards, we recommend moving to the sys5.3 environment. > This is born out by the compiler defining __STDC__. It is true that the 6.7 C compiler defined __STDC__. This was done, I'm told "... as a convenience for those programmers wanting to add the incremental features Apollo implemented without defining their own HAS_PROTOTYPES, HAS_CONST, ..." (I never bought that myself.) The fact that we defined __STDC__ before we had an ANSI C preprocessor led to problems with code of the form: #ifdef __STDC__ <use some new ANSI C feature> #else <do it the old way> #endif The older compilers would gag on some ANSI C feature which should have been eaten by the C preprocessor. This led to much frustration, and on occasion, code of the form: #if defined(__STDC__) && !defined(apollo) <use some new ANSI C feature> #else <do it the old way> #endif Which now has to be changed back when you move to the 6.8 compiler. Of course, if you have code which you need to be able to compile in both the 6.7/pseudo-__STDC__ environment and a real __STDC__ environment, you're still stuck with the problem mentioned above. As a workaround, our ANSI CPP predefines __STDCPP__. This permits you to code as follows: #if !defined(__STDC__) || (defined(apollo) && !defined(__STDCPP__)) <the old way> #else <the new way> #endif Which is portable, (as long as 'apollo' is only defined on Apollo machines), and will allow your code to compile in both the 6.7 C and 6.8 C environments. This tidbit missed the sr10.3 release notes, so you might want to save it away for future reference. The fact that 'apollo' is defined in the 6.7 environment is a minor compliance bug in its own right; 6.8 doesn't define it in strict ANSI mode. > Just what is '#attribute' supposed to mean? I assume it is supposed to be > picked up by the preprocessor, but isn't that what #pragma is for? The #attribute Apollo extension is well documented in the Domain C Language Reference. It is part of the compiler, rather than preprocessor, syntax. An alternate syntax has been available for a while. The example from stdio.h now reads: ... __attribute((aligned(1))) The cr1.0 compiler groks both #attribute and __attribute, and has changed #options to __options as well. These changes are documented in the release notes for the 6.7 and 6.8 releases respectively. The include files were not changed so that they would continue to work with earlier C compilers. All names beginning with two underscores are explicitly reserved to the implementation, so there should be no conflict with conforming applications. Furthermore, the syntax is such that you can #define it out of your way in order to compile with gcc. Of course you have to make sure that gcc will produce the same code that our CC produces when it sees those modifiers. > (from string.h - this is wrapped inside of an '#ifdef __STDC__') > extern char *strcpyn(...); This is fixed in sr10.3 include files. If you compile in strict ANSI mode, the include files will give you exactly what the ANSI C standard calls for. > On the subject of the semiANSIness of the Apollo cc, peering at my > a configuration file I have here the following weirdness applied under 10.1. > I think most of them still apply under 10.2 (we run it but I haven't checked). > - "const" doesn't work. const, signed, and volatile support was added at cc 6.7. 6.8 produces more diagnostics when you don't use them consistently. > - the ANSI #include files aren't there (limits.h and so forth). They're in sr10.3. > - self-referential macros fail, viz > #define it(x) (fputs("hi\n",stderr),it(x)) Fixed in sr10.3 ANSI CPP. > - stdio isn't ANSI. Supposedly fflush(NULL) will flush all streams. Fixed in sr10.3 /lib/libc. > Then rumour is unprecise. What is true is that the 6.8 compiler is an > ANSI one, but only if you run it under SR10.3. And then the programs > you compile with the ANSI option set will not run under SR10.2 and > earlier (at least that is how I read the documentation). This is true. In order to be 100% compliant with the ANSI C standard, various symbols referenced in standard header files had to be changed. _iob is the most obvious example. The standard reserves all *external* identifiers beginning with a single underscore to the implementation. However, macro names beginning with underscore and a lower-case letter are not reserved to the implementation. Thus a conforming application is permitted to say: #define _iob 123 #include <stdio.h> ... fprintf(stderr, "Nya, nya!\n"); To permit this to work correctly, we had to change the reference to _iob to something else; its now __iob. Of course sr10.2 nodes don't know from __iob, so the program won't work there. To answer this problem, the strict namespace conservations measures are taken only in strict ANSI mode. In other areas, <ctype.h> for example, it was not possible to provide the functionality required by ANSI C with the existing symbols. The changes made to solve these problems will be with us in both strict and extended ANSI modes. Third, there are new functions defined by ANSI C which were not present in sr10.2. It should be obvious that if you use these, your code won't run on the older versions of Domain/OS. We have defined a few macros which allow you to explicitly grant us permission to pollute your namespace to generate code which will run on older releases. These macros are well documented in the release notes and/or the new edition of the C Language Reference. obligatory disclaimers: *I* didn't even work here when "they" decided to turn on __STDC__. ;-) We don't promise that our ANSI CPP will define __STDCPP__ forever. Your mileage may vary. Void where prohibited, taxed, or unlawful. Questions about availability, price, etc. should go to your sales reps; I already told you as much as I know. Steve Valentine - smv@apollo.hp.com Hewlett-Packard Company, Apollo Systems Division, Chelmsford, MA Hermits have no peer pressure. -Steven Wright
rfg@NCD.COM (Ron Guilmette) (09/13/90)
In article <4cc44d3a.20b6d@apollo.HP.COM> smv@apollo.hp.com writes: > >In other areas, <ctype.h> for example, it was not possible to provide the >functionality required by ANSI C with the existing symbols. The changes >made to solve these problems will be with us in both strict and extended >ANSI modes. I'd like to see some elaboration on this. What exactly is so special about <ctype.h>? -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.