-1

Is there a resource listing CString fixes between VC6.0 and Visual Studio 2010. We have encountered what appears to be a compiler bug in VC6.0 sp6 that works in 2010.
I'm working to distill it into a small test case but essentially in cases where ~300 strings are referenced two nearly identical strings resolve such that one is lost at the assembly level. Seems like a possible internal hash table collision internal to vc6.0.

I need to prove this for a vc6.0 work around solution. (Our legacy code is vc6.0). I'll try to post a code snippet once I can / (if I can ) distill it to something I can post.

Ross Youngblood
  • 502
  • 1
  • 3
  • 16
  • `CString` is part of MFC, not a native type. IOW, not a compiler bug. Also, I have no idea what "two nearly identical strings **resolve** such that one is **lost at the assembly level**" even means. Also, "internal hash table collision" - VC++6 doesn't have internal hash tables. There's `CMap` of course, but that's unrelated to `CString`. – MSalters Jan 07 '16 at 11:28
  • i understand CString was re-written between VS6 and later broken out of MFC. That's where my CString reference came from. I have yet to step into this code myself. In VS 2010, two different calls passed two different strings resolve at the assembly level to two unique pointers the code works. In vc6 the two different strings resolve to the same pointer. A string is lost. – Ross Youngblood Jan 08 '16 at 15:01
  • Still unclear what you mean by "a strings resolves to a pointer". `CString` _contains_ a pointer, but I'm now playing guessing games.. – MSalters Jan 08 '16 at 15:06
  • Our QA/ developers have confirmed that the string bug is related to the use of the /ZI flag. (debug with edit and continue). Switching to /Zi (Without debug and continue) fixes the problem in VC++ 6.0.
    . Our QA engineer found this link http://computer-programming-forum.com/80-microsoft-visual-c-vc/969b6154dd542a55.htm. Regarding string pooling. The bug appears to be in the string pooling of the compiler. I'll post more when I know more.     – Ross Youngblood Jan 14 '16 at 04:38
  • 1
    Right, not CString then, but the compiler itself. You'll be in for a surprise as you upgrade to newer compilers. The "bug" isn't in the compiler, but in your code which modifies string literals. This has _always_ been illegal. With C++11, the responsible conversion (dropping `const` from `const char*`) has been eliminated. – MSalters Jan 14 '16 at 08:23
  • We are NOT modifying the string literals. The problem here is that the string pooling algorithm in Visual Studio 6 is LOSING a string when string pooling is used. By "LOSING", I mean that the pooling algorithm is deciding that TWO DIFFERENT strings are the same.We have been using this code base for over 10 years, and recently have customers with LOTS of SIMILAR strings due to some code generation tools, that is triggering bug in code that has been static for many years. – Ross Youngblood Jan 14 '16 at 18:18
  • https://msdn.microsoft.com/en-us/library/aa235442(v=vs.60).aspx – Ross Youngblood Jan 14 '16 at 18:42

1 Answers1

1

Visual C++ uses COMDAT naming to support the /GF string pooling flag (which is implied by /ZI) However, under VC++6.0 the symbol name length was truncated to 256 characters.

I suspect your strings have identical prefixes up to the 256th character.

Community
  • 1
  • 1
MSalters
  • 173,980
  • 10
  • 155
  • 350
  • We actually had two cases where string pooling was causing issues. The first we had a customer with VERY LONG strings, so I suspect this may have been an issue. In the second case the strings were 8 character's long. – Ross Youngblood Feb 18 '16 at 23:06