Bug in ossimString::split

[jmalik]

Following ossimString refactoring, it seems like a bug appeared in split. The bug appears when running :

ossim-info -p <QB_product> | grep -n "image0.projection.support_data.band_name_list"

I get "B" while I should get "B G R N" Also, I only have image0.projection.support_data.B_band_absCalFactor: 0.0160412 in the kwl. while I should have also the G, R and N equivalent.

The issue has been tracked down to ossimString::split

Changing "ossimString copyString = *this;" by "ossimString copyString = this->c_str();" fixes the issue (as weird as it appears!)

IMHO, the real cause behind this is the use of strtok. Look at the doc (​http://www.cplusplus.com/reference/clibrary/cstring/strtok/): the first parameter is a char*, not a const char*, because the argument is modified.

In ossimString::split it is bypassed by a const_cast, which appears to be a wrong option in this specific case.

Applying the method of ​http://www.cplusplus.com/reference/string/string/c_str/ fixes the issue too (allocation of a char buffer with the right size, copy the content delivered by c_str(), then use this buffer in strtok calls).

Please also consider the fact that strtok is not reentrant, and as such is known to be evil. Is it thread safe ?

This is a blocking issue for OrfeoToolbox : we can't do radiometric calibration of QB or WV2 imagery anymore.

[jmalik]

just added a patch (ossimString.diff) which solves the problem (but still rely on strtok...)

[gpotts]

I have refactored the ossimSTring split routine to use cont_iterator for a single pass split. I have added to the ossim-string-test a couple more variations.