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

[Arthur David Olson]

> "extern char exit();" is plain wrong on EVERYbody's system.  Whether
> or not this causes a problem depends on the implementation.
> If a header is included that has e.g. "extern exit();" in it
> then there is a type clash, too.

Thanks for the posting; these points should definitely help in improving my
comment.  Let's see if I can get some more help.

Consider this code:
	-------------------------
	extern void * malloc();
	char *
	getten()
	{
		return malloc(10);
	}
	--------------------------
where this dumb function just returns a point to ten character's worth of
allocated storage.  Now if we
	#define void int
as the standard suggests for backporting purposes, "old" compilers will happily
compile the code without complaint--and on systems where (int *) != (char *),
all hell will mysteriously break loose at runtime.

In this case, if we
	#define void char
the problem is avoided.

So:  are there any instances where a
	#define void char
will introduce runtime problems (that is, cause "quiet changes")
rather than causing compile-time problems ("noisy changes")?
(Again, I'm interested in concrete examples.)
-- 
		Grocery swaps ends for Chinese native.  (5)
	ado at ncifcrf.gov			ADO is a trademark of Ampex.