Boost C++ Libraries: Ticket #5086: Fix for possible assertion failure in MSVC isctype.c

attachment set

Tue, 18 Jan 2011 18:29:09 GMT

attachment → boost_tokenizer_tolerate_negative_char.patch

svn diff for trunk r68230

version changed

Tue, 18 Jan 2011 18:46:17 GMT

version Boost 1.45.0 → Boost Development Trunk

Marshall Clow — Sat, 22 Jan 2011 16:37:45 GMT

Good explanation; I see the problem that needs to be fixed.

However, it seems to me that this patch will change the behavior of non-MS systems.

isspace ( -5 ) will become isspace ( 251 ) - is that correct?

Sat, 22 Jan 2011 17:16:46 GMT

isspace ( -5 ) will become isspace ( 251 ) - is that correct?

Yes. But the former was undefined behavior. I think change to any certain behavior from undefined behavior is enough convincing.

Marshall Clow — Sat, 22 Jan 2011 17:32:50 GMT

I don't see where that's undefined behavior (except on MS-systems)

Looking at the C specification (since the C++ one defers back to that), all I see is:

7.4.1.9 The isspace function

Synopsis:

#include <ctype.h>
int isspace(int c);

Description: The isspace function tests for any character that is a standard white-space character or is one of a locale-specific set of characters for which isalnum is false. The standard white-space characters are the following: space (’ ’), form feed (’\f’), new-line (’\n’), carriage return (’\r’), horizontal tab (’\t’), and vertical tab (’\v’). In the "C" locale, isspace returns true only for the standard white-space characters.

Is there something that I'm missing?

Sat, 22 Jan 2011 17:53:54 GMT

Is there something that I'm missing?

Yes, here: 7.4 Character handling <ctype.h> p1

The header <ctype.h> declares several functions useful for classifying and mapping characters. 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.

Marshall Clow — Mon, 24 Jan 2011 15:57:16 GMT

Thanks for the pointer.

But I still see a problem with the path, specifically, when handling EOF. Casting EOF into an unsigned char will make it "not EOF" any more.

Thu, 27 Jan 2011 16:39:13 GMT

But I still see a problem with the path, specifically, when handling EOF.

A value char(EOF), which become equal to EOF after integer promotion if EOF is representable by char, in a string should never be treated as end of file in the first place.

This patch will somewhat cure that case, too.