Thread: Is this safe?

I think this is the point tmouse is trying to make.

Code:

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

int myisprint(int value)
{
   if ( value < 0 )
   {
      puts("Bzzzt!"); /* potentially undefined behavior */
      return 0;
   }
   return isprint(value);
}

void foo(const char *text)
{
   puts("foo");
   for ( ; *text; ++text )
   {
      myisprint(*text);
   }
}

void bar(const char *text)
{
   puts("bar");
   for ( ; *text; ++text )
   {
      myisprint((unsigned char)*text);
   }
}

int main(void)
{
   static const char text[] = "Ich möchte"; /* some text I googled */
   foo(text);
   bar(text);
   return 0;
}

/* my output
foo
Bzzzt!
bar
*/

Quzah, if char is signed by default, characters with a negative numerical value will yield undefined behaviour on Anonytmouse's implementation, even though those values are prefectly valid.

Originally Posted by Quzah

Don't you just hate being wrong?

Please.

> if char is signed by default
It isn't - an unqualified char may be signed or unsigned.

gcc for example has -fsigned-char and -funsigned-char compilation options to fiddle things when code makes the wrong choices.

Originally Posted by Sang-drax

Quzah, if char is signed by default, characters with a negative numerical value will yield undefined behaviour on Anonytmouse's implementation, even though those values are prefectly valid.
Please.

Newsflash: EOF is negative! Now be a good little programmer and go read the EOF FAQ.

Since I know it'll be too much work for you to go read yourself, I'll give you another version of the FAQ:

C: A reference manual, 5th edition. Page 365.

The value EOF is conventionally used as a value that signals end of file--that is, the
exhaustion of input data. It has the value of -1 in most traditional implementations, but Stan-
dard C requires only that it be a negative integral constant expression.

So what part of negative and integeral are you two not understanding?

Don't you just hate being wrong?


Quzah.

EOF is an exception -- all other negative numbers passed to is* and to* will invoke undefined behavior.

[edit]Read the Chris Torek post that tmouse posted earlier.

It's not an exception. It's a requirement. It is required by the standard to be supported. Now it's your turn to go read the EOF FAQ. Can no one here read any more? Come on Dave! You know better. Why is this wrong?

Code:

char c;

while( (c = getchar()) != EOF )
    ...damn, too bad that's a char...

It's wrong. You're wrong. They're wrong. Have a nice day.


Quzah.

7.4 Character handling <ctype.h>
1 The header <ctype.h> declares several functions useful for classifying and mapping characters.166) In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined.

So, how many unsigned chars have negative values?

So how many typecasts to a negative value, which just happens to be EOF still accurately represent EOF? Oh, and what is EOF again? That's right, any negative number, as defined by your compiler. Let me say that again, because you apparently can't grasp the concept:

EOF can be any negative number.

One more time, all together: "What happens when you typecast EOF to an unsigned char?"


Quzah.

Originally Posted by quzah

Let me say that again, because you apparently can't grasp the concept:

EOF can be any negative number.

It can be any one number -- it is not the same as all negative numbers.

(Really, the Torek piece explains this much better than I do.)

Right. So where again in your automatic casting to an unsigned char do you even remotely consider EOF? Oh, that's right, you didn't. That makes it wrong now doesn't it?


Quzah.

The is* and to* functions have defined behavior for EOF.

You clearly aren't understanding. How does casting EOF to an unsigned char give you the correct result from any is* or to* function? It doesn't. Therefore, casting to an unsigned char is wrong. How can you possibly get an accurate result from an is* or to* function when you've just typecast your data to something else entirely? EOF is handled. Yes. But what happens when you've now butchered EOF so it is no longer EOF?


Quzah.

You're right, I've gotten lost a little here. I don't have to worry about EOF because my data was in a string. As some of the previous links pointed out, if the value comes from fgetc and the like, the cast is undesired. But for the example I posted, the cast prevents UB by mapping a negative value into the range of unsigned char.

If your data was in a string, then you don't even have to worry about negative values. So again, the cast is pointless, as I stated earlier. Also as I stated earlier, the call to the function is not the place to be making sure your data is correct. You make sure it's correct and then you pass it, or you don't pass it at all.


Quzah.

http://groups-beta.google.com/group/...a8ff53f0?hl=en

Code:

I have no idea when the last discussion was, but yes, something like
this is a good idea.  It applies to all the <ctype.h> functions.  The
problem is that their domain -- the set of values they take -- is
{EOF, [0..UCHAR_MAX]}.  That is, toupper(EOF) is defined; toupper(0)
is defined; toupper(1), toupper(2), toupper(3), etc., are defined;
toupper(128) through toupper(255) are all defined; and if UCHAR_MAX
exceeds 255, additional toupper()s are defined.

On the other hand, unless EOF is -40, toupper(-40) is *not* defined.
If plain "char" is signed, and if "char *p" happens to point to a
plain "char" that has a value of -40, then:

        toupper(*p)

is *not* defined.  (It gives rise to the dreaded "undefined behavior".)
You can write either of these:

        toupper((unsigned char)*p)
        toupper(*(unsigned char *)p)

which have different meanings on one's complement and sign-and-magnitude
systems.  So, which one you should write depends on what is in the
memory to which "p" points.

All "normal" characters are nonnegative, so toupper('a') is definitely
'A', whether 'a' is 0x61 (ASCII) or 0x81 (EBCDIC) or something else
entirely.  (This implies that, on 8-bit EBCDIC systems such as IBM
mainframes, plain "char" must in fact be unsigned.)  So if "p"
points to normal text, the undefined-behavior aspect of touppper(*p)
will not rear its ugly head.  Unfortunately, all *that* really means
is that bugs tend to get past testing, and produce undefined behavior
when someone in Europe runs ISO-Latin-1 text through the program.

[edit]http://www.stanford.edu/~blp/writing...type-cast.html

Of course, if you store the return value of one of these function in a char object, then pass the char, the cast becomes necessary again.

As in,

Code:

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

int myisprint(int value)
{
   if ( value < 0 )
   {
      puts("Bzzzt!");
      return 0;
   }
   return isprint(value);
}

/* embedded nasty character: ö */
int main(void)
{
   char buffer[1024];
   int i, j;
   for ( i = 0; i < 1024; ++i )
   {
      int c = getchar();
      if ( c == EOF )
      {
         break;
      }
      buffer[i] = c;
   }
   for ( j = 0; j < i; ++j )
   {
      if ( myisprint(buffer[j]) )
      {
         /* putchar(buffer[j]); */
      }
   }
   return 0;
}

/* my output
C:\Test>test < test.c
Bzzzt!
*/