sullivan@vsi.UUCP (Michael T Sullivan) (07/16/88)
The default when regcmp(1) is called by:
regcmp file
is to put its output into "file.i", with the idea that "file.i" is #include'd
into your C source file. Shouldn't this be "file.h", especially in light
of the fact that the .i suffix is used by "cc -P" for its output? I use
"cc -P src.c", or I "cc -E src.c > src.i", so if I want to clean up some
things like *.o I also remove *.i. Besides, I thought .h was always the
suffix for files to be #include'd. Comments?
--
Michael Sullivan {uunet|attmail}!vsi!sullivan
V-Systems, Inc. Santa Ana, CA sullivan@vsi.com
ons, workstations, workstations, workstations, workstations, workstations, workolapw@olgb1.oliv.co.uk (Tony Walton) (07/22/88)
In article <757@vsi.UUCP>, sullivan@vsi.UUCP (Michael T Sullivan) writes: > The default when regcmp(1) is called by: > > regcmp file > > is to put its output into "file.i", with the idea that "file.i" is #include'd > into your C source file. Shouldn't this be "file.h", especially in light > of the fact that the .i suffix is used by "cc -P" for its output? ...... As I understand it, the sequence is prog.c ---> /lib/cpp ---> prog.i (preprocessor stage) prog.i ---> /lib/comp ---> prog.s (compilation to native assembler code) and so on. The prog.i, prog.s etc aren't normally seen unless you stop the sequence (cc -P runs only as far as the creation of prog.i, for example). cc is "intelligent" enough to run only the relevant parts of the subsystem; there's no point, for example, in running cpp on a file which has either already been preprocessed or which doesn't need it anyway (ie it has no comments, #defines, #includes, etc. regcmp produces code which needs no cpp run; this is shown by putting it in a .i file. You then #include the file in a .c file (the .h suffix is purely a convention, by the way). cpp is run on this .c file and the .i file is included. -- Tony Walton, OEM/VAR Division, British Olivetti Ltd., Wellington House, 154-160 Upper Richmond Road, London, England SW15 2FN LONDON, SW15 2FN. Tel: (+44) 1 789 6699 Telefax: (+44) 1 785 6670 Telex:27258 Uucp : { ukc | mcvax!olnl1 | ihnp4!cuuxb | iconet | olhqma } !olgb1!olapw
sullivan@vsi.UUCP (Michael T Sullivan) (07/28/88)
In article <539@olgb1.oliv.co.uk>, olapw@olgb1.oliv.co.uk (Tony Walton) writes: > > cpp run; this is shown by putting it in a .i file. You then #include the > file in a .c file (the .h suffix is purely a convention, by the way). cpp is > run on this .c file and the .i file is included. I have had several letters along this line. But I also have had a letter or two saying that some pre-processors will only #include files with the .h suffix. Is this a rare occurence? I can definitely see why one may want to put regcmp output into a .i file, but if not everybody can do it, is it still a good idea? -- Michael Sullivan {uunet|attmail}!vsi!sullivan sullivan@vsi.com V-Systems, Inc. Santa Ana, CA How about this, Dave?
guy@gorodish.Sun.COM (Guy Harris) (07/28/88)
> I have had several letters along this line. But I also have had a letter or > two saying that some pre-processors will only #include files with the .h > suffix. Is this a rare occurence? I sure hope so. Any compiler that doesn't take #include <...> and use the "...", unadorned and uncensored, to find the file in the "standard' include directories shouldn't be discarded lightly; it should be thrown back at its vendor with great force. If it, for example, supplies the ".h" as a "favor", so that you can say #include <stdio> or, worse, *refuses* to work if you say #include <stdio.j> the person who decided to provide those features should be gently chastised if it's their first offense and shot if it's their second. (The first feature is useless because anybody who wants this stuff to work on a wide variety of UNIX systems has to do "#include <stdio.h>" anyway; it also happens to follow the UNIX "cc" convention that you mention the full name of the source file, ".c" suffix and all. The second one is a botch: if "stdio.j" is a typo, it will probably be detected when the system fails to find "stdio.j"; if it does find "stdio.j", I think the chances are good that it's not C code and the compiler will barf; if it *is* C code, maybe it wasn't a typo and it was *supposed* to be included.) Now, I happen to *like* the convention that include files' names end with ".h" - it makes header files easier to find, and makes it easier to guess that a file *is* a header file - but that's a different matter. Then again, I also happen to like REGEXP(5) better than REGCMP(3X), because 1) it's what "ed", "sed", "pg", etc. now use, 2) it's in the SVID (REGEXP(BA_LIB)), which REGCMP(3X) isn't, and 3) it's not in the "-lPW" library. With REGEXP(5), the only thing I have to include is <regexp.h>, and that ends with ".h".... (No arguments about the implementation technique, please; arguments 1), 2), and 3) - especially 2) - weigh much more than any such arguments, at least in my book. I can rely on REGEXP(5) being on systems more than I can rely on REGCMP(3X) being on them.)