cosell@BBN-PROPHET.ARPA (01/22/86)
From: Bernie Cosell <cosell@BBN-PROPHET.ARPA> There have been a few comments about how all the .h files work (or don't). The trouble is neither with AmigaDOS nor the C compiler: there are simply *bugs* in the include files. The problem is that in, say, intuition.h it'll define some struct whose fields are all sorts of other intersting structs -- intution.h *MUST* #include *ALL* of the files it'll need to insure that those structures are, themselves, declared. And those #include files must be careful to, themselves, #include the files to define the structs and parameters that *they* need, and so on. Unfortunately, there are a fair bunch of missing #includes, and that shows up in the necessity of simple C programs having to include *piles* of extraneous .h files that it really shouldn't. It is pretty clear how these problems arose: obviously at some early epoch of the system the .h files were all clean and correctly treed. Then, as the system evolved, folks added new fields to various structures and the later adders were not so careful, and so errors crept in. I've fixed my system to have mostly rational .h file setups: what I've done is be scrupulos about *NOT* being willing to include gratuitous .h files. When I get an error out of lc1, I search through the include hierarchy for the undefined field or parameter that was missing. The search will uncover two things: a) files that use the structure or field or parameter, and b) the file that defines it. With a little bit of thought it is pretty easy to psyche out just what the `correct' tree of internal-includes ought to be. You edit it in and you're include world moves closer to rationality. In pretty short order you're all fixed up! (In one or two cases, as I recall, you not only have to #include a suitable file, but you also have to upgrade the file to have the "#ifndef DIR_FILENAME_H" hack to aviod multiple-includes. It's pretty obvious when you get into it...) an apology: I would have been delighted to post the actual changes it takes to fix thing up... but... I did *not* really keep track of what I was doing. I got annoyed one evening at the include=file craziness and, in my naivete, I I really thought that I'd find one little edit to fix and I'd be done, so I just dove in and began tweaking ...and tweaking... and tweaking. Sorry about that! But it really did only take about 1/2 hour to do the whole thing. /Bernie
bruceb@amiga.UUCP (Bruce Barrett) (01/23/86)
Version 1.1 of the development system (Lattice V3.03) includes 2 solutions to (some of) the recent complaints about the .h files. 1) All .h files now include the .h files they require to compile 2) The warning "error #61" which complained about pointers within structures pointing to undefined structures has been removed. Yes we realized it was a problem, yes we were busy testing and fixing other things, yes it is now fixed. Sorry for the inconvience. --Bruce Barrett
mykes@3comvax.UUCP (Mike Schwartz) (01/24/86)
Another crude but effective way to make more sense out of the header file nonsense is to change all pointers to structures into ULONGs. This will remain portable (with MANX and lattice). Only those structures that have nested structures in them cannot be fixed this way. In the programs that use particular structures, you should cast the ULONG back into a pointer to the structure of appropriate type. This may sound clumsy, but it will make a lot of 'C' source code generate smaller object code!