Re: basic_string causes crash in _vsnprintf???

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

The problem is the scope of calls to examine:
1. Any var args function (we use a lot for logging and internal tracing
mechanisms and we log and trace everywhere) - Probably several thousand of
these calls for our tracing and a few general purpose varargs calls that
would need to be searched for.
2. Specific printf familty methods, printf, sprintf, vsprintf,etc. We have
about 2000+ obvious references to just these.
3. TRACE family of methods, and any other output string sets used. Probably
several thousand of these calls.

I don't really have the time to scrutinize 6-10,000+ references and correct
them. So it seems the only quick and almost guaranteed alternative is to
create a custom implementation of basic_string that mimics the behavior we
want or revert back to the old stl. Still surprised MS didn't support a
compatiblity mode for string references like they did for CString.




"Carl Daniel [VC++ MVP]" wrote:

> WXS wrote:
> > As someone said both StlPort and CString took great pains to support
> > this functionality so while it was not a standard STL implementation
> > it was an implementation specific functionality that could be relied
> > upon from those vendors.
>
> In STLport it's just (bad) luck that it "works". AFIAK, only CString was
> really designed to permit this abuse. I don't know what version of STLport
> you're using, but looking at the STLport 4.6.2 source code, you're already
> in trouble. Try this code with your STLport:
>
> #include <string>
> #include <stdio.h>
>
> int main()
> {
> std::string s("Hello");
> printf("%s%s%s\n",s," cruel"," world");
> }
>
> I expect that you'll see "Hello{garbage}" printed, because the STLport
> std::string object has the size of three pointers, all of which get pushed
> onto the stack when a std::basic_string instance is passed to a varargs
> function. The first pointer points to the start of the string, the second
> points to one past the end of the valid content of the string. If you're
> using an older STLport that uses COW (copy on write) strings, then you've
> got other problems (google for COW string - lots has been written about the
> pitfalls).
>
> > So the code is not proper to the STL standard baseline implementation
> > but it is valid for the vendor specific implementations that chose to
> > support it. It is surprising microsoft's implementation does not
> > given stlport chose to.
>
> Actually not. The VC7+ implementation of std::string implements what's
> known as the "small string optimization" by storing small strings directly
> in the std::string object instead of in a separate memory allocation. This
> optimization can result in a significant performance improvement for
> programs that use a lot of small strings (a not-uncomon usage pattern).
> Implementing the small-string optimization eliminates any possibility of
> making the brute-force cast to const char* work (because the object size is
> larger than a pointer).
>
> > I agree with the point it is not proper STL usage as per spec of the
> > STL standard, just we have a lot of code that relied on a specific
> > implementation that did work well with the ms crt libraries.
> >
> > The problem with migrating the code is that anywhere a basic_string
> > was used we have to make sure there are no calls to ANY variable
> > argument methods which include any printf family of functions. Even
> > closely examining all the code would not likely guarantee nothing was
> > missed so I'd like to find a way to make the basic_string work like
> > it used to.
>
> Take the time now to fix the code rather than working hard to find a way to
> keep the ill-formed code you have now. In the long run, you'll be glad you
> did.
>
> > The options I'm considering to have a better guarantee of success:
> > 1. Checking with MS to see if they encountered this and have an
> > option for their STL to do this (slim chance but worth a check)
>
> No such option, guaranteed.
>
> > 2. Go back to using STL port instead of the MS version of STL
>
> You could do that, and have a less conformant STL, but your ill-formed code
> would still "work".
>
> > 3. create an enhanced CString with stl functionality such that any
> > code using stl like syntax will work and will support the behavior
> > some code relied upon.
>
> That seems pointless to me.
>
> > The last option would be to go through every line of code and examine
> > it to see if c_str() needs to be called, that seems VERY error prone,
> > so seems like it is not a good option at this point. I need
> > something that will most definately work and in the shortest time
> > possible (Usual software development schedules you know :) )
>
> This is the only sensible option, IMO. How many varargs functions do you
> have? In nearly 30 years of programming, I can scarcely recall writing one
> that wasn't some sort of wrapper over printf and given a similar name.
>
> -cd
>
>
>
.

Relevant Pages

  • Re: basic_string causes crash in _vsnprintf???
    ... > this functionality so while it was not a standard STL implementation ... In STLport it's just luck that it "works". ... The first pointer points to the start of the string, ... > So the code is not proper to the STL standard baseline implementation ...
    (microsoft.public.vc.stl)
  • Re: basic_string causes crash in _vsnprintf???
    ... As someone said both StlPort and CString took great pains to support this ... implementation specific functionality that could be relied upon from those ... So the code is not proper to the STL standard baseline implementation but it ... It is surprising microsoft's implementation does not given stlport chose to. ...
    (microsoft.public.vc.stl)
  • Re: STL Slow - VS2005
    ... Here is the file that was tested with vs2005 stl and vs2005 w/stlport 5.0 ... // IN VC8 namespace std is used ... #pragma message ("USING STLPORT") ... string func ...
    (microsoft.public.vc.stl)
  • Re: why use the sealed ?
    ... > I'll want to add functionality to something at a later date. ... > I sortof wish you could add functionality to (or replace members of) ... > exceeds past the end of the string. ... > application to be a Remoting Client. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Predicting the Future and Kolmogorov Complexity
    ... to the source string), k scales with the string, thus destroying the ... excess of symmetry or a lack of it that strikes you as particularly ... The same thing is true of radio signals. ... What do I mean by levels of functionality? ...
    (talk.origins)