Hi,
I use isalpha() in a ported application which could generate some
special characters equal, between others, to 65532.
isalpha() crashes (memory fault) when it tests that value.
I suppose that’s not normal !?!
regards,
Alain.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
I use isalpha() in a ported application which could generate some
special characters equal, between others, to 65532.
isalpha() crashes (memory fault) when it tests that value.
I suppose that’s not normal !?!
The application is in error. According to IEEE POSIX 1003.1-2001,
the description for isalpha() is:
“The c argument is an int, the value of which the application shall
ensure is representable as an unsigned char or equal to the value of
the macro EOF. If the argument has any other value, the behaviour
is undefined.”
Presumably this is to allow fast array-based implementation. You
must range-check the value first if it is possibly not EOF/0x00-0xFF.
This caveat applies to isalnum, isalpha, isblank, iscntrl, isdigit,
isgraph, islower, isprint, ispunct, isspace, isupper; only exception
is isascii.
Hi John,
John Garvey a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
I use isalpha() in a ported application which could generate some
special characters equal, between others, to 65532.
isalpha() crashes (memory fault) when it tests that value.
I suppose that’s not normal !?!
The application is in error. According to IEEE POSIX 1003.1-2001,
the description for isalpha() is:“The c argument is an int, the value of which the application shall
ensure is representable as an unsigned char or equal to the value of
the macro EOF. If the argument has any other value, the behaviour
is undefined.”
Hum, well, say that the application has been written on a more nice
system. :-
Presumably this is to allow fast array-based implementation. You
must range-check the value first if it is possibly not EOF/0x00-0xFF.
This caveat applies to isalnum, isalpha, isblank, iscntrl, isdigit,
isgraph, islower, isprint, ispunct, isspace, isupper; only exception
is isascii.
Ok,
Alain.
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
I use isalpha() in a ported application which could generate some
special characters equal, between others, to 65532.
isalpha() crashes (memory fault) when it tests that value.
…
Hum, well, say that the application has been written on a more nice
system. :-
Does that other system actually promise that isalpha() returns a
sensible value when the argument is greater than UCHAR_MAX? Maybe it’s
just a coincidence that it didn’t crash on that system, too? Maybe it’s
just a coincidence that it returned zero? (I suspect the application
relies on it returning zero, doesn’t it?)
If it does make such a promise, does it also mention that it’s an
extension that ANSI and POSIX don’t require?
Hi Wojtek,
Wojtek Lerch a écrit:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
I use isalpha() in a ported application which could generate some
special characters equal, between others, to 65532.
isalpha() crashes (memory fault) when it tests that value.
…
Hum, well, say that the application has been written on a more nice
system. :-
Does that other system actually promise that isalpha() returns a
sensible value when the argument is greater than UCHAR_MAX? Maybe it’s
just a coincidence that it didn’t crash on that system, too? Maybe it’s
just a coincidence that it returned zero? (I suspect the application
relies on it returning zero, doesn’t it?)If it does make such a promise, does it also mention that it’s an
extension that ANSI and POSIX don’t require?
I really don’t know. Sure the application didn’t take care of the
validity of the argument.
We used Intel C libraries, I don’t if they took care to prevent crash or
if it was a coincidence.
Anyway even if the behaviour could be undefined (according to POSIX
definition) a memory fault issue is a bit severe, from my point of view.
But ok, if it’s ‘normally’ expected…
Regards,
Alain.
I really don’t know. Sure the application didn’t take care of the validity
of the argument.
We used Intel C libraries, I don’t if they took care to prevent crash or if
it was a coincidence.
Anyway even if the behaviour could be undefined (according to POSIX
definition) a memory fault issue is a bit severe, from my point of view.
But ok, if it’s ‘normally’ expected…
I would think a fault is much more desirable than something that silently
does “something” - better the devils you know than the ones you don’t.
Just my $0.02
-Adam
Adam Mallory wrote:
I would think a fault is much more desirable than something that silently
does “something” - better the devils you know than the ones you don’t.
Absolutely. If only every piece of code that was wrong, immediately resulted in a crash…
Rennie