More ANSI comment help wanted: #define void int vs. #define void char

[Doug Gwyn]

I think this is a nonissue on which too much effort is being expended.
The original example (#define void int) is just an illustration of why
it MIGHT under SOME circumstances be USEFUL to be permitted to use
#define to redefine keywords.  NO redefinition of "void" is UNIVERSALLY
proper.

To take a specific case:  Although I did not draft the part about
"#define void int", my applications are prepared to do just that when
the (non-ANSI) C compilation environment warrants, as it does on older
4BSD systems and on some microcomputer C implementations (those that
do not provide the "void" extension to K&R [1st Edition] C).  The
specific mechanism I use is to include, in virtually EVERY application,
a private header <std.h> that I set up once for each compilation
environment.  This defines a bunch of stuff the implementation of which
varies from system to system but the use of which remains the same.
Here is an extract of relevant portions of one implementation of <std.h>:

typedef char	*pointer;		/* generic pointer (void *) */

#define	const		/* nothing */	/* (undefine for ANSI C) */

/* ANSI C definitions */

#ifndef EXIT_SUCCESS
#define	EXIT_SUCCESS	0
#endif
#ifndef EXIT_FAILURE
#define	EXIT_FAILURE	1
#endif

/* other kludges for deficient C implementations etc.: */
/*#define	strchr	index		/* 7th Edition UNIX, 4.2BSD */
/*#define	strrchr	rindex		/* 7th Edition UNIX, 4.2BSD */
/*#define	void	int		/* K&R 1st Edition followers */

Notice the last line.  I came up with this well before X3J11, and I
have seen other programmers do the same.  Notice also that my
applications NEVER contain the "void *" that you worry about being
broken by "#define void int"; instead I always use the generic
"pointer" type for such pointers, and define it appropriately in
this header.

So in my situation, "#define void int" is sometimes useful, but
"#define void char" never is (and can be harmful).  There is
certainly no need to change the X3J11 example.