🚀 go-pugleaf

> Balderdash!!!!!
> K&R declare all chars as ints so that routines that return EOF will
> work correctly regardless of whether chars are signed or unsigned
> in your hardware/software combination.

This is irrelevant to how *arguments to functions* are declared.  K&R
declares those variables into which "getc" or "getchar" store their values
as "int"s because the value of "getc" (and thus "getchar") *is* an "int".
This also has nothing to do, strictly speaking, with whether "char"s are
signed or unsigned.  In *either* case, storing the value of "getc" into a
"char" and comparing it with EOF will fail.  Assuming that EOF is -1 (as it
is in most, if not all, UNIX implementations of the standard I/O library),
then:

	If "char"s are signed, then reading in a character with the
	value '\377' (assuming 8-bit characters; perform appropriate
	translation for other character sizes) and assigning it to a
	"char" variable assigns a value to that variable that will
	be considered equal to -1.  Thus, a program looking for EOF
	will see one, and think it reached the end of the file.

	If "char"s are unsigned, then when "getc" encounters the end
	of the file, it will return -1, which when assigned to a "char"
	variable will give that variable a value equal to '\377' (again,
	assuming 8-bit characters; your mileage may vary).  This value
	will not be considered equal to -1, but will be considered
	equal to 255.  Thus, a program looking for EOF will never see it.

Declaring to argument to "foo" in the example given in previous postings
will not affect whether the program can properly detect end-of-file, unless
the result of "getc" is being passed to "foo" and "foo" is testing whether
it's an EOF.  If the result of "getc" is being passed to any routine, that
argument to that routine should be declared as "int" since the result of
"getc" is an "int".

> Your compiler is broken if it will not work as shown in the example,
> and if you define the arg as an int in the subroutine, you \'should\'
> cast the char arg to an int in the calling sequence.  The automatic
> promotion of char to integer only means that everything will probably
> work if you don't do the casting.

No, the automatic promotion of "char" to "int" is 100% equivalent to a
promotion using a "cast".  If you declare:

	char c = 'w';

then

	foo(c);

and

	foo((int)c);

are equivalent - if this isn't ANSI C or there is no function prototype
declarator in scope that declares the argument to "foo" as a "char".  If
this is ANSI C, and there is such a function prototype *declarator* in
scope, then the argument is *not* promoted automatically.  Note the use of
the word "declarator":

	void
	foo(ch)
		char ch;
	{
		...
	}

	int
	main(argc, argv)
		int argc;
		char **argv;
	{
		char c = 'w';

		foo(c);
		...
	}

will cause the promotion, but replacing the definition of "foo" with

	void
	foo(char ch)
	{
		...
	}

will not cause the promotion, because in the first example when "foo" is
used it is declared as "void foo(...)", while in the second example it is
declared as "void foo(char)".
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)