Boost C++ Libraries: Ticket #2970: Out of boundary access with STLport

summary changed; cc set

Ulrich Eckhardt — Fri, 29 May 2009 06:27:02 GMT

cc Ulrich Eckhardt added
summary Out of boundary access with STLPort → Out of boundary access with STLport

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 — Fri, 05 Jun 2009 09:08:11 GMT

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 — Sat, 06 Jun 2009 06:27:20 GMT

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.

status changed; resolution set

anonymous — Thu, 18 Jun 2009 15:13:19 GMT

status new → closed
resolution → invalid

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.