char's and int's

[s0suk3]

I've seen a lot of functions in the standard library that deal with
characters, but a lot them return/take parameters of type int (which
is usually the integer that represents the character code in the
character set). I know that C automatically converts between int and
char in those cases without problems (or could the singed/unsigned
issue cause problems?), and that character constants have actually
type int, but, what is the reason for some functions in the standard
library to return type int (or take parameters of type int) when one
is supposed to be dealing with characters instead of numbers?

Thanks,
Sebastian

 

[rahul]

I've seen a lot of functions in the standard library that deal with
characters, but a lot them return/take parameters of type int (which
is usually the integer that represents the character code in the
character set). I know that C automatically converts between int and
char in those cases without problems (or could the singed/unsigned
issue cause problems?), and that character constants have actually
type int, but, what is the reason for some functions in the standard
library to return type int (or take parameters of type int) when one
is supposed to be dealing with characters instead of numbers?

Thanks,
Sebastian

Cosider fgetc(). It actually returns an unsigned integer cast to an
int. Casting to the int is required because EOF is defined as negative
int(generally, but not necessarily, -1). So, other than the EOF, we
get an unsigned int.

 

[gw7rib]

rahul said:



Since chars are integers, you are correct.


No, other than the EOF we get an int that is the result of a conversion of
an unsigned char to an int.

Don't you mean "a conversion of a char to an int" ?

 

[gw7rib]

(e-mail address removed) said:


No, I don't mean that.

Then could you explain, please? My understanding is that a type char
is provided, for storing, well, characters, in the system's favourite
format. Functions such as fgetc() are used for reading in characters,
but the output they give has to embrace both all real characters and
have something different to indicate EOF. Hence they return an int. So
I would have assumed that the values they can return, other than EOF,
are the values of characters which in turn are the values a char can
have. I don't see where you have got "unsigned" from. AFAIAA you
should use unsigned char rather than char when reading memory
locations storing a different type but I don't see how that is
relevant here.

Paul.

 

[Keith Thompson]

I've seen a lot of functions in the standard library that deal with
characters, but a lot them return/take parameters of type int (which
is usually the integer that represents the character code in the
character set). I know that C automatically converts between int and
char in those cases without problems (or could the singed/unsigned
issue cause problems?), and that character constants have actually
type int, but, what is the reason for some functions in the standard
library to return type int (or take parameters of type int) when one
is supposed to be dealing with characters instead of numbers?

In very old versions of C (pre-1989), function prototypes did not
exist. An expression of type char passed as an argument would always
be promoted to int, and a function with no visible declaration was
assumed to return int.

 

[Keith Thompson]

Then could you explain, please? My understanding is that a type char
is provided, for storing, well, characters, in the system's favourite
format. Functions such as fgetc() are used for reading in characters,
but the output they give has to embrace both all real characters and
have something different to indicate EOF. Hence they return an int. So
I would have assumed that the values they can return, other than EOF,
are the values of characters which in turn are the values a char can
have. I don't see where you have got "unsigned" from. AFAIAA you
should use unsigned char rather than char when reading memory
locations storing a different type but I don't see how that is
relevant here.

That's what the standard says.

C99 7.19.7.1:

If the end-of-file indicator for the input _stream_ pointed to by
stream is not set and a next character is present, the _fgetc_
function obtains that character as an _unsigned char_ converted to
an _int_ and advances the associated file position indicator for
the stream (if defined).

Plain char may be either signed or unsigned. Forcing the characters
read from a file to be treated as unsigned char rather than plain char
ensures that no valid character can appear as EOF.

Typically EOF is -1. On a system with 8-bit bytes, where plain char
is signed (two's-complement), a byte with all bits set will be read as
255. If it were interpreted as a plain char, it would be read as -1.

 

[rahul]

Cosider fgetc(). It actually returns an unsigned integer cast to an
int. Casting to the int is required because EOF is defined as negative
int(generally, but not necessarily, -1). So, other than the EOF, we
get an unsigned int.

My mistake; I meant an unsigned char converted to an int so that it
can accommodate EOF.

 

[gw7rib]

[Snip detailed explanation including...]

         int fgetc(FILE *stream);

Description

   The fgetc function obtains the next character (if present) as an
unsigned char converted to an int , from the input stream pointed to
by stream , and advances the associated file position indicator for
the stream (if defined).

Ah. You live and learn. Thanks very much to you and to Keith for
filling me in on this point.

Paul.