>> Far from being ideal, the current solution is _broken_, and results
>> in incorrect code.
> I assume you are refering to code like
[compressed vertically -dM]
> int foo(char c) {  }

Actually, I think it was referring to stuff like

[header file]
int foo(char);

[source file]
int foo(c) char c; { ... }

which is not valid C, though we get away with it because it's valid gcc
(provided the prototype is in scope at the point of definition).  Of
all the ways in which gcc differs from C, this is one of the ones I
like least.

> which IMHO is usually bogus.  [...]  And if you were not frobbing
> hardware what is the point of using a char or short?

Speaking personally, as someone who sometimes writes (prototyped) code
with functions that take sub-int arguments, the point is conceptual
type-correctness.  If an argument is a character with which something
is to be done, it's conceptually a char and I write it so.  If the
argument is conceptually a frob_t, I call it a frob_t, even if that's a
sub-int type.  (If frob_t's definition is not part of my code, I may
not even know it's a sub-int type; if it's an opaque handle, I may not
know it's even an integral type.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B