Thread: Is this safe?

Originally Posted by Dave_Sinkula

"My program only breaks if I pass it this data?" Must be a problem with the data.

My point was to test the data for problems, and not cast it into something it's not.

On an aside, all of your put* functions use unsigned chars for output, at least according to the man pages. So using them with your funny-o has already converted it to an unsigned character. Whose argument that helps I'm not sure.

At any rate, the issue you were having was implementation specific. If you had read your data in as unsigned characters, or, if you had forced your char to be unsigned, you wouldn't have that problem ever. But again, my main point was that blanket typecasts won't catch EOF.

I still stand by 'test your data, then pass it to functions' rather than just blanket casting it so it fits. Hell, I could use only void * and with the right casts pass anything to whatever I felt like. It doesn't make it a good way to do things.


Quzah.

Yes, either test that the value is within [0,UCHAR_MAX] or force it to be. And EOF shouldn't be put into a string.

>Store a character with the value 255 in a signed char and see what happens
tolower() and similar functions take an int, not a signed char.

There are two situations for reading data. One is where EOF is involved, where you must use integers instead of chars to hold the input (functions like getchar). Do not cast anything to chars in this situation and you'll be fine.

The second one involves functions like fgets, where you do not have to worry about EOF. Here you can either declare the chars as unsigned and you don't have to worry about casting the char later on. If you make an unqualified declaration, so the char can be either signed or unsigned, you MUST cast the char to unsigned just before it gets promoted to int in the is* function, like this isalpha((unsigned char)c). Otherwise you'll get undefined behaviour if you've read in an non-ASCII value in a signed char.

So to sum it up, there's really only one scenario where you need to cast to unsigned.

Originally Posted by ^xor

> tolower() and similar functions take an int, not a signed char.

You're missing the point though... Since the functions must be able to check for EOF, they also accept negative integer values. And since any negative value except EOF is undefined, it's possible to cause undefined behaviour by sending negative values that do not equal EOF.

It sounds like you misread what I said:

>(unless you manage to match the value of EOF in the conversion).
Which you won't ever do, since EOF is a negative value.

>Try to store the value 255 in a signed char
I don't see any code that Anonytmouse, Dave, or anyone else posted that stores in a signed char which is passed to toupper(). I do see an int cast to an unsigned char. Perhaps that's what you mean.

> I don't see any code that Anonytmouse, Dave, or anyone else posted that stores in a signed char which is passed to toupper().

But you do see lots of code that uses unqualified chars? On my system, unqualified chars default to being signed, so if an user inputs the iso8859-1 character 'y umlaut' (255), you'll end up saving -1 instead.

What everyone is arguing about, is whether or not you should cast to unsigned char when you use the ctype functions. What I said was that there's only ONE scenario where you should do the cast, and that is when you're getting input from functions that does not return EOF. If you're using functions that return EOF, the variable storing the return value should be an int, so there's no point in making a cast here, and in fact it's wrong since you'll end up trashing EOF eventually! That's what quzah tried to explain.

However, when you store input from functions like fgets in unqualified chars, you MUST do the cast or you'll end up sending negative values to the ctype functions whenever you encounter non-ASCII characters (assuming the unqualified char defaults to signed). EOF is not an issue here since fgets does not return EOF or save it in the buffer.


> I do see an int cast to an unsigned char.

That is WRONG if that int is used for saving the return value from functions that return EOF.

I apologize, I misread your original post, the part in parentheses. For some reason I thought you meant the conversion to unsigned char, but you specifically said in the case where there is no conversion, so I goofed.