Compilier bug? const std::string is writeable

[Christopher_W_1]

Hi all,

this piece of code is rejected by gcc, however icpc on Linux (tested: v14 and 15)

• does not complain about using a non-const-iterator / changing a const string,
• and changes the content of the string passed as const, not only in the copy inside cv2up, but also in main.

#include <algorithm>
#include <string>
#include <iostream>
 
using namespace std;
 
void cv2up(const std::string typ) {
      // convert to upper case
      std::transform(typ.begin(), typ.end(),typ.begin(), ::toupper);
      cout << typ << endl;
}
 
int main() {
  string typ("abc");
  cout << typ << endl;
  cv2up(typ);
  cout << typ << endl;
  return 0;
}

 
$ icpc conststr.cpp && ./a.out
abc
ABC
ABC

Regards,

    Christopher

[jimdempseyatthecove]

Though I may be wrong on this. I think you have declared a "const array of char" as opposed to "array of const char". The former inhibits you from altering the array pointer, the later inhibits you from altering the elements of the array. I think you need to use something like:

void cv2up(std::basic_string<const char> typ) {

Note, I haven't tried the code, you may need to reinterpret case at the call points.

Jim Dempsey

[Judith_W_Intel]

I agree Intel should produce an error.

If you preprocess it and compile that you will see the error, i.e.:

ptel37-54> icpc -P conststr.cpp
sptel37-55> icpc -c conststr.i
conststr.i(13698): error #137: expression must be a modifiable lvalue
        *__result = __unary_op(*__first);
        ^
          detected during instantiation of "_OIter std::transform(_IIter, _IIter, _OIter, _UnaryOperation) [with _IIter=__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, _OIter=__gnu_cxx::__normal_iterator<const char *, std::basic_string<char, std::char_traits<char>, std::allocator<char>>>, _UnaryOperation=int (*)(int)]" at line 36146

compilation aborted for conststr.i (code 2)
sptel37-56>

The underlying problem is that our compiler suppressed discretionary errors that come from system headers (like string and stl_algo.h).

We need to make an exception for errors that are actually useful (i.e. indicative of a potential runtime problem) like this one. This was recently already submitted by another user as DPD200380931 and we just fixed it and have confirmed fixes this problem. This fix did not make the code cutoff for 16.0 update 2 but will be in 16.0 update 3.

thanks for reporting it.

Judy

[Kittur_G_Intel]

Thanks Judy, I added this issue to DPD200380931  so I can monitor and update this thread when the release with the fix is out, appreciate much.

_Kittur

[Kittur_G_Intel]

Hi,
Just letting you know that this issue is fixed in the 16.0.3 (update 3) release that was out this week which you can download from the Intel Registration Center and  test it out, thanks.

Regards,
Kittur