need help with a delcaration
Chris Torek
chris at umcp-cs.UUCP
Sun Sep 14 19:30:46 AEST 1986
>In article <2233 at gitpyr.UUCP> thomps at gitpyr.UUCP writes:
>>If I understand what Kernighan and Ritchie say in their book, then ch
>>is automatically converted to an int when foo is called because a function
>>argument is an expression and a character is always converted to an int in
>>an expression. See K&R page 41 - 42.
This is correct. Actually, this is an understatement: C does
not have a character type.
Wait! Let me explain what I mean by this.
The C language has what I call `expression types' and `storage
types'. There is a character storage type, but there is no character
expression type. The following is a list of storage types and
equivalent expression types:
Storage Type Expression Equivalent
------------ ---------------------
char int
unsigned char unsigned int
short int
unsigned short unsigned int
int int
unsigned int unsigned int
long long
unsigned long unsigned long
float double
double double
pointer pointer
(Some C compilers have different flavours of pointer; I believe
the Data General MV series distinguish between `char *' and `other
pointer', as do PR1ME compilers. One proposed architecture has a
different kind of pointer for each possible size datum.)
This peculiarity simplifies the compiler, often at the cost of some
run-time efficiency. It also leads to several pitfalls. In general,
if you write what you mean, you should be safe; and if you write
what the compiler does, you should also be safe. (There is an
advantage to writing what you mean: A good compiler may be able
to produce better code in such cases. Unfortunately, there is a
disadvantage as well: A poor or mediocre compiler will often
produce worse code.)
>>I know that some compilers take care of this and allow you to
>>still declare ch as a char. However, I note that K&R always declare
>>ch as an int in their examples. I would suppose that the compiler being
>>used requires the int declaration.
Then it is not a C compiler.
>>Since the conversion occurs by definition of the language, there is
>>no danger in declaring it an int
(other than possible confusion on the part of the programmer)
>>and this is commonly done in most C code.
As I mentioned in the `soundex debate', I do this myself, with some
reservations.
In article <547 at chinet.UUCP> rlk at chinet.UUCP (Richard Klappal) writes:
>Balderdash!!!!!
Not at all.
>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.
K&R, p. 127:
type(c) /* return type of ASCII character */
int c;
{
if (c >= 'a' && c <= 'z' || c >= 'A' && c <= 'Z')
return(LETTER);
else if (c >= '0' && c <= '9')
return(DIGIT);
else
return(c);
}
p. 79:
char buf[BUFSIZE]; /* buffer for ungetch */
int bufp = 0; /* next free position in buf */
...
ungetch(c)
int c;
{
if (bufp > BUFSIZE)
printf("ungetch: too many characters\n");
else
buf[bufp++] = c;
}
(To be fair, an exercise on page 80 or so suggests extending ungetch()
to handle ungetch(EOF).)
p. 42:
Since a function argument is an expression, type conversion also
take place when arguments are passed to functions: in particular,
char and short become int, and float becomes double. This is
why we have declared function arguments to be int and double even
when the function is called with char and float.
>Your compiler is broken if it will not work as shown in the example,
Agreed.
>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.
Now *this* is (to borrow your word) balderdash. If by this you
mean `for clarity, I think you should', then I will agree; if
you mean `for proper operation, in strict C compilers, you must',
to this I object: it is not so.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP: seismo!umcp-cs!chris
CSNet: chris at umcp-cs ARPA: chris at mimsy.umd.edu
More information about the Comp.lang.c
mailing list