Thread: Understanding ctype.h

It's for portability. Sometimes characters are 1 bytes. Sometimes they are 2 bytes for extended characters like chinese characters. In the future, it may be even more. So toupper takes an int to make sure that there is no data loss (like if you had to convert a 2 byte character into a 1 byte character).

http://groups.google.com/group/comp....de5e6e1dcf2e4e

The reason the argument and return types are int is similar to that for getchar() - the function is defined for values representable as unsigned char and also EOF (which has a negative value). Any other value passed to toupper results in undefined behaviour (which is why it is sometimes necessary to case the argument to ctype.h funtions to unsigned char before passing it).

An example here.

And don't use gets.

Don't use gets. And no, it isn't a problem, since a char fits easily within an integer.
And yes to your first question, as well.

This makes sense logically but why doesn't the following modification work( data type changed from char to int )?

Code:

/*
exercise 8.6
Write a program that inputs a line of text with function gets into char array
s[ 100 ].  Output the line in uppercase letters and in lowercase letters.
*/

#include <stdio.h>
#include <ctype.h>

int main()
{
  int *sPtr;
  int s[ 100 ] = { 0 };
  sPtr = &s[ 0 ];

  gets( s );


  while( *sPtr != '\0' ) {
    printf( "&#37;c", toupper( *sPtr ) );
    ++sPtr;
  }

  printf( "\n" );

  sPtr = &s[ 0 ];
 
  while ( *sPtr != '\0' ) {
    printf( "%c", tolower( *sPtr ) );
    ++sPtr;
  }

  printf( "\n" );

  return 0;
}

Code:

root[~]# cc -Wall -pedantic 8.6.c
8.6.c: In function 'main':
8.6.c:16: warning: passing argument 1 of 'gets' from incompatible pointer type
/tmp/ccTPmiTC.o: In function `main':
8.6.c:(.text+0x42): warning: the `gets' function is dangerous and should not be used.
root[~]# ./a.out
abcd
a
a
root[~]#

I'm guessing it might have something to do with the while condition. An integer can't be equal or not equal to '\0' ?

I know gets isn't safe to use, but it's part of the exercises in my book. I'm using this as an opportunity to learn about data types and functions.

Gets is unsafe and can easily be substituted for fgets.
fgets(s, sizeof(s), stdin);
Go ahead. Change it.
Gets should never have been invented. It should not exist. So consider it doesn't exist and never use it, whatever the reason you have to use it. No excuse.
And neither gets nor fgets reads an integer. They read a string. That's different.

If you want an in depths explanation:
An array is just one contiguous block of memory. In case of char, each element is 1 byte.
However, fgets just writes directly to the memory, each character is one byte. So in the char array, each element represents one character.
With your int array, you get 4 characters in one element because int is 4 bytes.

If you want to test your theory, you can do:
printf( "%c", toupper( (int)*sPtr ) );
Or
int n = (int)*sPtr;
printf( "%c", toupper(n) );

This assumes s is a pointer to char and s is an array of char.
And s is not a good name for a variable either.

>Sometimes characters are 1 bytes. Sometimes they are
>2 bytes for extended characters like chinese characters.
Not really, in more ways than one.

First, Chinese is a bad example for the two byte explanation because the current Chinese logogram collection is probably pushing 100,000 unique characters. Assuming a byte is the smallest addressable unit, you need at least three bytes to cover the most recent dictionary, which still isn't complete.

Second, "char" in C is synonymous with "byte". That's not going to change, and that's why the framework around wchar_t exists to support larger character sets than a byte can handle.

The real reason for why toupper and friends work with int instead of char is consistency throughout the standard library. All of the ctype functions are defined in terms of input based on fgetc. fgetc allows the full range of unsigned char and EOF, which is a negative value. For toupper to support the range of values returned by fgetc, it has to use a signed data type larger than unsigned char.

>why doesn't the following modification work( data type changed from char to int )?
Put simply, int is used in the ctype library to support an error flag of EOF. It doesn't mean you can suddenly use int to process characters unless you add the requisite logic to treat single integers as single characters, which isn't the default behavior. For example, this works because I changed gets to a function that expects a pointer to int:

Code:

/*
exercise 8.6
Write a program that inputs a line of text with function gets into char array
s[ 100 ].  Output the line in uppercase letters and in lowercase letters.
*/

#include <stdio.h>
#include <ctype.h>

void jsw_gets ( int *s )
{
  int ch;

  while ( ( ch = getchar() ) != EOF && ch != '\n' )
    *s++ = ch;

  *s = '\0';
}

int main()
{
  int *sPtr;
  int s[ 100 ] = { 0 };
  sPtr = &s[ 0 ];

  jsw_gets( s );

  while( *sPtr != '\0' ) {
    printf( "%c", toupper( *sPtr ) );
    ++sPtr;
  }

  printf( "\n" );

  sPtr = &s[ 0 ];
 
  while ( *sPtr != '\0' ) {
    printf( "%c", tolower( *sPtr ) );
    ++sPtr;
  }

  printf( "\n" );

  return 0;
}

All arguments < 4 bytes are promoted to 4-bytes values and passed to printf.
(And floats are promoted to doubles.)
So when you want to print &#37;c, it actually reads 4 bytes, and interprets it, then displays it.
You could use %s to display an int, yes, but that is not recommended, due to how strings work.

Originally Posted by yougene

int is 4 bytes and char is 1 byte. I pass a char value to toupper and toupper returns an int value. The int value is printed as a char by %c, so what happens to the other 3 bytes? Would I be able to print 4 characters by using %s to display an int value?

I'm going to have to switch over to fgets but one thing at a time. Apparently I'm doing alot wrong, I got my data types all mixed up, my naming scheme sucks, and I'm using the wrong functions!

A char is, as you say 1 byte. The compiler can translate char into int (it does that by filling the remainging 3 bytes with the upper-most bit of the char [1] - many processors even have a specific instruction for this particular purpose).

So when you pass a char to toupper() it is automatically "extended" to an int.

The opposite isn't true, because the compiler won't know that your int only contains char's (and like you can ride a bicycle throug a wide lane on a road, but a bus won't fit on a cycle-lane, the compiler will say "stuff an integer array into a char - no way, it doesn't fit there"). This is why it says "passing argument 1 of 'gets' from incompatible pointer type"

When it comes to printf(), it has special rules: Since the compiler doesn't understand how the arguments to printf are going to be treated, it passes ALL small integer values (shorter than long) as int, and all float values as double. This is part of the C language standard. So your char value will be translated into an int anyways.

[1] Unsigned char will be converted by filling the top 3 bytes with zero.

--
Mats

Originally Posted by yougene

If I would print that first element using %s I would probably get the rest of the strings( although not recommended ).

Then you would print the entire string.
And don't use gets.

Originally Posted by yougene

Ok I think this is coming together now. The reason the int modification didn't work was due to the way gets enters information into memory. It just takes the starting point of memory and directly enters information regardless of what data type I'm using. The reason the program only gave back a instead of abc is because the rest of the string( "bc" ) was still located in the first element of the array. If I would print that first element using %s I would probably get the rest of the strings( although not recommended ).

It will actually work just fine to print with printf("%s", s), because gets() and printf() will both interpret the string as a char array. The fact that you declared it as an int array will only come into effect if you try to step throgh it, then you will get 'abcd' (0x64636261) as the integer value [1] of the first integer - because gets() have stuffed four bytes into the first four bytes of your array.



[1] or 0x61626364, depending on the "endianness" of the machine.

--
Mats