Out of boundary access with STLport

[Jazz]

In lexical_cast.hpp, line 519, it is assumed that empty strings end with a null char, but this is not true with STLPort :

char last_grp_size = grouping[0] <= 0 ? CHAR_MAX : grouping[0];

grouping[0] has an undefined value when grouping is empty. I propose this to fix it :

char last_grp_size = grouping_size == 0 || grouping[0] <= 0 ? CHAR_MAX : grouping[0];

[Ulrich Eckhardt]

The expression 's[s.size()]' is okay on a string, as long as 's' refers to a const string. Now, it would be interesting which version of STLport you have and how it behaves, i.e. how you detected a misbehaviour, because a missing zero would be a bug there.

The code in question is this:

            std::string const& grouping = np.grouping();
            [...]
            char last_grp_size = grouping[0] <= 0 ? CHAR_MAX : grouping[0];
            // a) Since grouping is const, grouping[grouping.size()] returns 0.

Note especially the comment, which basically repeats what I wrote above.

[anonymous]

Replying to eckhardt:

The expression 's[s.size()]' is okay on a string, as long as 's' refers to a const string. Now, it would be interesting which version of STLport you have and how it behaves, i.e. how you detected a misbehaviour, because a missing zero would be a bug there.

I didn't know this, do you have a reference explaining this? I have STLPort 5.0.0.

[Ulrich Eckhardt]

There is pretty little explanation, but it is simply written in the C++ standard. I guess that this is a compromise made to help migration from char* strings, because there you could also access all elements from str[0] to str[size] inclusive.

Now, what I still don't know is what exactly you are seeing. Is STLport's debug mode throwing an out-of-bounds access or is something else failing? Can you provide some code that fails?

Lastly, STLport 5.0.0 was released 2005-11-02! That's almost four years ago! Further, since I partially maintained the STLport port to MS Windows CE, I know that there is actually a test-case for the above behaviour, though I'm not sure when exactly the test was added and (possibly) the behaviour fixed. If I were you, I would consider upgrading, at least to the last 5.0 release. OTOH, current compilers usually come with a well-working C++ stdlib, so just using the native one would make things easier generally.

[anonymous]

Replying to eckhardt:

Now, what I still don't know is what exactly you are seeing. Is STLport's debug mode throwing an out-of-bounds access or is something else failing? Can you provide some code that fails?

In this code, when str is "1024", sometime it returned 1024, sometime 1 :

boost::lexical_cast< unsigned >( str );

The change I provided fixed that.

Lastly, STLport 5.0.0 was released 2005-11-02! That's almost four years ago! Further, since I partially maintained the STLport port to MS Windows CE, I know that there is actually a test-case for the above behaviour, though I'm not sure when exactly the test was added and (possibly) the behaviour fixed. If I were you, I would consider upgrading, at least to the last 5.0 release. OTOH, current compilers usually come with a well-working C++ stdlib, so just using the native one would make things easier generally.

Probably we should upgrade STLPort. We are using STLPort in a cross-platform project, and on some platforms some features are not available with the C++ compiler.