Path: utzoo!utgpu!attcan!uunet!nuchat!texbell!bigtex!milano!cs.utexas.edu!sm.unisys.com!ucla-cs!admin.cognet.ucla.edu!casey From: casey@admin.cognet.ucla.edu (Casey Leedom) Newsgroups: comp.sys.apollo Subject: Re: SR10: /usr/include/apollo/{base,time}.h and cc -A nansi ... Keywords: SR10, Ansi C, non Ansi C, Apollo include files Message-ID: <17532@shemp.CS.UCLA.EDU> Date: 3 Nov 88 20:48:52 GMT References: <17508@shemp.CS.UCLA.EDU> Sender: news@CS.UCLA.EDU Reply-To: casey@admin.cognet.ucla.edu.UUCP (Casey Leedom) Organization: UCLA Cognitive Science Program Lines: 135 | From: Larry Allen | | | From: Casey Leedom | | | | The latest chapter in my endless quest to get X.V11R3 compiled on SR10. | | (Note that my partner in crime will be submitting a amusing little | | conversation he had with Apollo regarding the missing header files in | | /usr/include/netinet.) | | It's very simple why we didn't ship all the "missing" header files in | : they're all internal kernel include files that aren't used | on Apollo (different TCP implementation). None of them, to the best of | my knowledge, declare any user-program-visible data types or constants. | Can you give us a list of the include files you need and what you need | them for? If there are some that are really useful to user applications, | we'll ship them. First off tcp(4p) explicitly mentions . Secondly a fairly major piece of software, X V11, includes this file. I don't know about the rest of the files missing from . My guess is that you should include the entire set and simply #ifndef apollo ... #endif the sections you don't feel you can support properly. Those sections will almost certainly be machine dependent and therefore not used by any application. This is also an assumption however, and may also get you into trouble. | | Several bugs really: | | | | 1. Apparently Ansi C defines the sequence "##" to be interpreted by the C | | Preprocessor (cpp) as a null string which can be used to separate | | macro references and allow their expansions to be concatenated | | properly. (Many older sources used the non-portable "/**/" | | equivalent.) Ex: | | | | #define foo(a, b) a##b | | | | The Apollo SR10 compiler totally barfs on this. Therefore I have to | | compile X.V11R3 with -A nansi. If the "##" construct is truly a part | | of Ansi C, can we get an update to Apollo's cpp that handles it | | properly? | | Yes, this is unfortunate but true. The problem is that the SR10 C | compiler is NOT a fully ANSI-compliant C compiler. In fact, the only | ANSI feature it really supports is function prototypes. This argues that | we shouldn't really be using __STDC__ as the flag to indicate presence of | function-prototype support in the compiler and include files. However, | it's too late to change this now; the fix will arrive when we finally | ship a true ANSI-compliant C compiler (no, I don't know when this is | scheduled for, sorry). If it's not an Ansi C compiler Apollo *definitely* should not be using __STDC__. I'm offended that Apollo has. I wish that ANSI had trademarked the symbol and forced anyone using it to validate their compiler. | | 2. I was finally able to find something I could ifdef on to decide | | whether to try to include /sys/ins/base.ins.c or | | /usr/include/apollo/base.h - I used _BFMT__COFF. I couldn't use | | __STDC__ for the above reason. So I have: | | | | #ifdef apollo | | #ifdef _BFMT__COFF | | #include | | #include | | #else | | #include "/sys/ins/base.ins.c" | | #include "/sys/ins/time.ins.c" | | #endif | | ... | | #endif | | | | In X.V11R3/lib/Xaw/Load.c. We really need something more along the | | lines of ``#ifdef SR10'' for this kind of thing however. | | | | 3. Continuing with Load.c, it turns out that base.h and time.h (and | | probably several other files in /usr/include/apollo) have Ansi C | | functional prototypes declared. They don't ifdef the external function | | declarations on __STDC__ even though it's available, properly | | implemented by the Apollo compiler, and specifically for this purpose. | | If people want, I will submit patches for these fixes. Can we get | | these installed in the standard Apollo release? | | You don't want to do that. The .h files in /usr/include/apollo must have | the function prototypes; that's how the compiler knows to pass the | arguments by reference as required by the underlying Pascal routines that | you're calling. We want these include files to generate compiler errors | when compiled without ANSI function prototype support, since otherwise | the generated code would have hard-to-diagnose run time errors resulting | from calling call-by-reference routines with arguments passed by value. But, but, but ... *sputter!* You tell me that Apollo doesn't really have an Ansi C compiler, therefore I'll have to compile a lot of stuff with the -A nansi (sic) flag, therefore anything that uses Apollo functionality, , is doomed to failure ... I mean, do you want to offer a real solution or just tell me what I can't do? I've offered a completely reasonable solution to the problem (especially considering that the Apollo compiler turns out *not* to be anywhere close to being an Ansi C compiler) and all you can say is that it's not a good idea. What *is* a good idea???? Don't get me wrong, I like functional prototypes. I like type checking (with an escape mechanism). I like what the Ansi C committee has done in general. But since all Apollo implements is just functional prototyping, and since Apollo has chosen to use the Ansi C define __STDC__ to falsely claim that the compiler is an Ansi C compiler (and worse yet, this is the default), I have to compile with the -A nansi compiler flag. What is it? You want maybe I (and everyone else across the net) should put the following type of code into our programs? #ifdef __STDC__ # ifdef apollo ... # else ... # endif #else ... #endif The conversion to Ansi C was already going to be enough of a hassle, though well justified. Now Apollo in their infinite wisdom has decided to complicate the picture. (Many expletives deleted.) I just don't believe this ... At least if Apollo is going to screw things up, DON'T STAND IN THE WAY OF PEOPLE WHO ARE TRYING TO WORK THEIR WAY AROUND THE PROBLEMS THAT APOLLO HAS CREATED. Casey P.S. I don't in general include disclaimers because I take that as the standard. However, I feel that I should at least make it explicitly clear that these are my opinions, that all postings I have ever made, or ever will make, unless explcitly stated otherwise, are mine.