mouse@mcgill-vision.UUCP (der Mouse) (07/29/86)
> Recently, through no fault of my own (honest, guv'nor!) I wound up > including a header file with no terminating newline. Fun, ain't it? > My questions are directed more toward the handling of the missing > newline itself: > What do other preprocessors do in this kind of situation? Well, in my preprocessor (yes, I rewrote cpp), a # is not special except at the beginning of a line. Hence we have the following: x.c contains #include "y.c" #include "z.c" #include "y.c" this is x.c contents y.c contains, without a terminating newline this is y.c contents z.c contains this is z.c contents then cc -E (with my preprocessor) produces # 1 "y.c" this is y.c # 2 "x.c" contents#include "z.c" # 1 "y.c" this is y.c # 4 "x.c" contentsthis is x.c contents Notice that the last token has migrated from the included file into the including file, and that the first #include has been output literally. > What *should* X3J11 say about these cases, if anything? I see nothing wrong with leaving it implementation-dependent (it is an error if the file does not end with a newline). On another topic, > __STR__ and __CAT__ were suggested by Tom Plum in a late-night > working session to resolve the remaining preprocessor issues, > The Reiser CPP is definitely out. I don't see what's wrong with Reiser cpp's answer to the str and cat problems (formal substitution in strings and /**/). Could someone enlighten me? The former (formals inside ""s) can bite, but only if you're not aware of it (using the same name for a formal and a global within the macro can bite too, so the possibility of being bitten will not go away with __STR__). The only thing I can see wrong with /**/ for __CAT__ is that cc -E -C, such as is used by lint, won't do contatenation, but the preprocessor could easily be made to strip /**/ even under -C). -- der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa "Come with me a few minutes, mortal, and we shall talk." - Piers Anthony, Bearing an Hourglass
meissner@dg_rtp.UUCP (Michael Meissner) (08/01/86)
In article <470@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > >> __STR__ and __CAT__ were suggested by Tom Plum in a late-night >> working session to resolve the remaining preprocessor issues, > >> The Reiser CPP is definitely out. > >I don't see what's wrong with Reiser cpp's answer to the str and cat >problems (formal substitution in strings and /**/). Could someone >enlighten me? The former (formals inside ""s) can bite, but only if >you're not aware of it (using the same name for a formal and a global >within the macro can bite too, so the possibility of being bitten will >not go away with __STR__). The only thing I can see wrong with /**/ >for __CAT__ is that cc -E -C, such as is used by lint, won't do >contatenation, but the preprocessor could easily be made to strip /**/ >even under -C). There are two main reaons why the reiser cpp's mechanisms (of stringizing and token pasting) have a different syntax in the draft X3J11 standard. First, it is nearly impossible to formalize in a step by step manner (and the main reason for standards is to formalize things), and also the reiser cpp violates K&R (where it states that comments are ALWAYS turned into whitespace, and where it explicitly states that text inside of strings and char constants. The relavant K&R quotes are: page 179: Blanks, tabs, newlines, and COMMENTS (collectively, "white space") as described below are ignored except as they serve to separate tokens. page 207: Text inside a string or a character constant is NOT subject to replacement. Michael Meissner, Data General, ...{decvax}!mcnc!rti-sel!dg_rtp!meissner
ron@brl-sem.ARPA (Ron Natalie <ron>) (08/05/86)
In article <490@dg_rtp.UUCP>, meissner@dg_rtp.UUCP (Michael Meissner) writes: > > page 207: > Text inside a string or a character constant is NOT subject to > replacement. > What is ambiguous here is whether they are talking about string and character constants in the program, or in the macro itself. -Ron