[net.lang.c] builtins and automatic defines

flaps@utcs.uucp (Alan J Rosenthal) (05/11/86)

Well I sure hope no one sticks in such a thing without telling me!
Any such #include or #define things should not only be optional, they
should have to be explicit.  So perhaps instead of merely beginning every
program with #include <stdio.h>, you can also have #include <builtins.h>.

*I* won't #include it, though...

Alan J Rosenthal
{linus|decvax}!utzoo!utcs!flaps, {ihnp4|allegra}!cbosgd!utcs!flaps

kwh@bentley.UUCP (KW Heuer) (05/14/86)

In article <1232@utcs.uucp> utcs!flaps (Alan J Rosenthal) writes:
>Well I sure hope no one sticks in such a thing without telling me!
>Any such #include or #define things should not only be optional, they
>should have to be explicit.  So perhaps instead of merely beginning every
>program with #include <stdio.h>, you can also have #include <builtins.h>.
>
>*I* won't #include it, though...

They should be semantically identical, so what do you care whether it's
optimized by default?

I wonder if perhaps <stdio.h> (and <builtins.h>) should be included by
default, with an explicit "#exclude" to disable.  (Cf. "#undef".)  Probably
tricky to implement -- don't do the automatic "#include" until checking for
"#exclude", which must be at the top of the file (after whitespace)?

I had much the same attitude when I learned of the (then) new features that
allowed structure copy/call-by-value/return-by-value.  I wasn't using them
(of course, since they were new), and I wanted to see an error if I used one
by mistake (forgotten "&").  I was hoping for a compatibility option of some
type, like EO in TECO-10.  (A nice feature that allowed TECO to simulate an
older version of itself, so as not to obsolete all old macros.)

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint

flaps@utcs.uucp (Alan J Rosenthal) (05/17/86)

In article <816@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes:
>I wonder if perhaps <stdio.h> (and <builtins.h>) should be included by
>default, with an explicit "#exclude" to disable.  (Cf. "#undef".)  Probably
>tricky to implement -- don't do the automatic "#include" until checking for
>"#exclude", which must be at the top of the file (after whitespace)?

Why bother?  This would be very complicated and lead to many mistakes due
to an unclear definition of whitespace or whatever.
I have a file called "beginc", it's a shellscript, and it creates a file
which begins something like this:

		#include <stdio.h>
		#include "/u/flaps/ajr.h"
		#include <strings.h>
		#define TRUE 1
		#define FALSE 0

		main(argc,argv)
		int argc;
		char *argv[];
		{

and then puts you in $EDITOR on the file.  This approach is much better
than any #exclude op.  It's more easily disabled or modified because you
don't have the reverse situation of deleting things by adding in lines.

--
Alan J Rosenthal
{linus|decvax}!utzoo!utcs!flaps, {ihnp4|allegra}!cbosgd!utcs!flaps

kwh@bentley.UUCP (KW Heuer) (05/23/86)

In article <1243@utcs.uucp> utcs!flaps (Alan J Rosenthal) writes:
>In article <816@bentley.UUCP> kwh@bentley.UUCP (KW Heuer) writes:
>>I wonder if perhaps <stdio.h> (and <builtins.h>) should be included by
>>default, with an explicit "#exclude" to disable.  (Cf. "#undef".)  Probably
>>tricky to implement -- don't do the automatic "#include" until checking for
>>"#exclude", which must be at the top of the file (after whitespace)?
>
>Why bother?  This would be very complicated and lead to many mistakes due
>to an unclear definition of whitespace or whatever.

It doesn't seem all that complicated to me, and probably seems simpler to
the neophyte who doesn't understand why he gets "stderr undefined" when his
program was working fine earlier.  The mistakes could be easily caught by
cpp: "#exclude must be at top of file".  I meant for "whitespace" to include
comments, otherwise I think it's quite clear (when restricted to the set of
characters that can legally appear in a C program).

>I have a file called "beginc", it's a shellscript, and it creates a file
[which contains several #include's and #define's and the start of main()]
>and then puts you in $EDITOR on the file.  This approach is much better
>than any #exclude op.  It's more easily disabled or modified because you
>don't have the reverse situation of deleting things by adding in lines.

Perhaps.  We already have the "delete by adding" situation with #undef,
though the analogy isn't perfect (you can't completely cancel an #include,
which is why #exclude would have to be first).

On a related note, I've always despised the automatic cpp builtins (such as
"#define unix 1" on UNIX(R) systems), because it effectively creates a new
reserved word for each possible operating system, machine, etc. that your
program might be compiled on.  Older versions got around this by making the
builtin definition be "#define unix unix", with a special kludge to prevent
infinite recursion.  I think the "who am i" testing should not use the same
namespace as the macros.

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint