dave@lethe.UUCP (David Collier-Brown) (11/13/88)
> In article <124300001@inmet> stt@inmet writes: >>A simple language extension would be: >> >>#include_once "classname.h" [definition of include_once as equivalent to #ifdef classname_h # include "classname.h" # define classname_h #endif ] From article <8387@nlm-mcs.arpa>, by mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum): > I wonder how much code would break is such an extension were added, > and the #include_once were made the DEFAULT rather than the exception ? I suspect very little: I used such a construct in a preprocessor for multiple languages without further thought, and my C programs tend to work correctly (they may, in fact, therefor be incorrect :-). I'm crossposting the question to comp.lang.c for further discussion. Ok, people! Would this change, made silently, injure correct programs? It is admitted that it may allow incorrect programs to compile, but that isn't waht I'm concerned about. Specifically, what about include trees which cannot be tsorted? --dave c-b
daveb@llama.rtech.UUCP (Dave Brower) (11/15/88)
In article <3414@geaclib.UUCP> geaclib!lethe!dave writes: >>>#include_once "classname.h" >From article <8387@nlm-mcs.arpa>, by mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum): >> I wonder how much code would break is such an extension were added, >> and the #include_once were made the DEFAULT rather than the exception ? > > Ok, people! Would this change, made silently, injure correct >programs? It is admitted that it may allow incorrect programs to >compile, but that isn't waht I'm concerned about. > Specifically, what about include trees which cannot be tsorted? Well, it will certainly break this year's Obfuscated C contest winner, which calulated prime numbers in the preprocessor with use of multiple inclusion and defined/undefed state variables. Some might say it is not a "proper" program, but it falls within the letter of the existing and proposed laws. -dB "You have to run twice as fast to get anywhere" - Ben Johnson. {amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com
jgm@k.gp.cs.cmu.edu (John Myers) (11/17/88)
In article <3414@geaclib.UUCP> geaclib!lethe!dave writes: >From article <8387@nlm-mcs.arpa>, by mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum): >> I wonder how much code would break is such an extension were added, >> and the #include_once were made the DEFAULT rather than the exception ? > > Ok, people! Would this change, made silently, injure correct >programs? It is admitted that it may allow incorrect programs to >compile, but that isn't waht I'm concerned about. Most certainly. There is a programming method used by the GNU C compiler and other programs which is to create a file of definitions (expressed as macro invocations) which gets included more than once. For example, in GCC the file tree.def contains lines like: DEFTREECODE (ERROR_MARK, "error_mark", "x", 0) DEFTREECODE (IDENTIFIER_NODE, "identifier_node", "x", 6) DEFTREECODE (TREE_LIST, "tree_list", "x", 2) One then defines the macro DEFTREECODE to do whatever one wants and then #include's tree.def. For example, in tree.c: #define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE, char *tree_code_type[] = { #include "tree.def" }; #undef DEFTREECODE #define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH, int tree_code_length[] = { #include "tree.def" }; #undef DEFTREECODE I also have a header file that generates a function to do a bitblt for a given binary operation. One #define's a macro to specify the binary operation and then #include's the file. This is usually repeated for each of the binary operations. -- _.John G. Myers Internet: John.Myers@cs.cmu.edu LoseNet: ...!seismo!inhp4!wiscvm.wisc.edu!give!up "The world is full of bozos. Some of them even have PhD's in Computer Science" --