Lucio De Re
unread,Jun 19, 2011, 8:18:31 AM6/19/11Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to golan...@googlegroups.com
It all starts with a comment in src/cmd/8a/a.y: "if we don't, bison will, and a.h re-#defines getc"
The Plan 9 native toolchain objects to the inclusion of <stdio.h> on the grounds that <stdio.h> is not self-sufficient as it is in the Posix environments. So the easy solution is to figure out a way to drop <stdio.h> conditionally. I haven't yet figured out a way to do this.
Instead, I tried to get to the bottom of the problem, applying the Plan 9 formula that says that header files should preferably not include other header files, but should be documented insofar as their prerequisites are concerned.
Suffice it to say that it is impossible to describe the contortions one needs to go through just to understand the interactions between 8a/a.y, 8a/a.h, 8a/lex.c, cc/cc.h, cc/lexbody, cc/lex.c, cc/macbody and cc/mac.c.
So, this is me throwing down the gauntlet: this stuff has driven me away from porting the Go toolchain to Plan 9 before, this time I intend to get it fixed. And fix the Plan 9 toolchain in the process. It will mean extensive re-arrangements of the contents of src/cmd/?a, src/cmd/cc, src/cmd/?c (but hopefully not src/cmd/gc or src/cmd/8g). If there are any strong views on this issue, now would be a great time to speak up.
My immediate bugbears are (a) alloc()/allocn() and their mirrors mal()/remal(): there were three different implementations last time I looked at this issue, with no hints why one should be chosen in preference to another; (b) is there a better way to define the lexical analyser than to #include various combinations of "lexbody" and "macbody" in various arbitrary modules?
I'm expecting that I'm not the first person to be confronted by this labyrinth, please feel free to share any thoughts, opinions and code with me.
Lucio.