Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: fgetpos, fsetpos, and ANSIness in general
Message-ID: <20064@mimsy.UUCP>
Date: 9 Oct 89 14:32:00 GMT
References: <OTTO.89Oct8093607@tukki.jyu.fi> <432@s5.Morgan.COM>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 85

In article <432@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:
>... One of the resident C experts ... once explained to me how to
>structure all my include files and always use function prototypes for
>sources with many files.  I was stunned to find how primitive C was
>compared even to the unit facility of early Pascals

(What `unit' facility?  Early Pascals required that the entire source
code be a single file.  Pascal had `forward' declarations, but not
`external's.  All modern Pascals allow separate compilation, but most
of them use different, incompatible methods.)

>and the sleek modernity of Modula-2.

Other than `see Modula 3', no comment.

>Why can't I have an array of function variables?

You also cannot have an array of feather variables, for the same reason:
There is no such thing as a function variable.  You can, however, have
an array of pointers to functions.

>Why do I need to creat a spurious structure name on the way to a
>recursive typedef? 

Because typedef name recognition must go in the lexer to build LALR
parsers for C.  Structure name parsing is context free, hence references
to them do not require that they already exist.

(Actually, the above question is also ill-phrased.  One cannot build
`recursive typedef's at all in C.  The closest thing to a recursive
type, and what you must have meant, is a self-referential structure
---a structure that contains a pointer to another instance of the same
structure, or a reference to itself via some chain of pointer references.)

On a different note entirely:
>... (indent introduced a syntax error due to somehow substituting *=
>where =* was required). This could only happen in C.

No, it could happen anywhere (consider what the Pascal program

	PROGRAM STUPID(INPUT, OUTPUT);
	VAR INPUTBUFFER[30];
	...

is likely to do when fed input lines longer than 30 characters), but
in this case the change from `=*' to `*=' is a `feature' of indent.
Long, long ago, in a history not far away (New Jersey, actually), the
C language had `=op' operators rather than `op=' operators.  One wrote

	char buf[] "initial value";

	main(argc, argv) char **argv; {
		int i 1;
		char *p;

		while (i < argc) {
			p = argv[i];
			if (*p == '-' && p[1] == 'c') {
				p =+ 2;
				...

Although indent does nothing about the `old fashioned initialisation's
above (`int i 1' and `char buf[] "..."'), it does do something about
the `old fashioned assignment operator': it turns it into a modern
assignment operator, by reversing the two characters `=' and `+'.
It does this for all possible old-style assignment operators, and due
to programmer error, some versions of indent also do it for `=!',
so that `a=!b' becomes `a!=b', although even old C did not parse
thing this way.

The =op operators were changed to op= operators because of the frequency
of mysterious answers from

	i=-1;	/* set i to -1 */

and

	a=*b;	/* set a to *b */

which is actually remarkably similar to the complaint that started this
discussion (a/*b).  Back then, when large disks were 5 MB, it sometimes
seemed important to squeeze white space out of source code. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris