need help with a delcaration
Guy Harris
guy at sun.uucp
Thu Sep 18 04:03:23 AEST 1986
> 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 at sun.com (or guy at sun.arpa)
More information about the Comp.lang.c
mailing list