Hello.
I have a question about the isdigit/isalnum/etc functions.
They are defined to receive an int as argument. So I ask: is it safe to
call them with a char arg?
Like this:
----
char c;
// changes the value of c
isdigit(c);
----
Considering that the char can be signed, it would be converted to the
range [-128, +127] as an int; inside the isdigit() function, will the
extra bits be ignored?
I noticed the values between [-128, +127] work fine without using
setlocale; but when setting to any locale that isn't "C", it crashes (I
actually use 'setlocale(LC_ALL, "");' ).
I also read in ISO/IEC 9899:1999:
"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."
Ok, then the behaviour is undefined. I respect this. BUT SOMEONE
implemented a networking library (aka: winsock anyone? :P) that uses
isdigit() inside some functions (like inet_addr); and guess what, it
actually passes a signed char to the isdigit function. It means that
whenever you set a locale, if you call inet_addr() with any non-ascii
char (that would be a negative if considered as 'signed char'), it
crashes inside the isdigit(). I confirmed this, stepping each assembly
instruction inside gdb, and inet_addr really calls isdigit() this way.
So I'm now asking myself:
1- Why the hell Microsoft is calling a locale-specific function to
validate inet_addr???? Does the other networking libs also use isdigit()
for this?
2- How can I call inet_addr in a program that uses setlocale? Should I
create a wrapper that checks for non-ascii chars before calling the real
inet_addr?
3- Should I try linking to libmsvcr71.a, so winsock would call isdigit()
from a different C runtime dll (msvcrt.dll) that isn't affected by my
call to setlocale() (msvcr71.dll)?
Thanks for any ideas.
Daniel K. O.
|
