[펌] vc 5, 6 stl 버그 픽스

http://www.dinkumware.com/vc_fixes.html


Fixes for Library Bugs in VC++ V5.0/V6.0

(as of 10 Nov 02)

---

The following bug fixes correct problems in the Standard C++ Library that accompanies Microsoft Visual C++ V5.0 and V6.0. Each replacement header file supplied here is represented as a .txt file, so you can view it directly with a web browser. You can also install the replacement file directly from the browser while you are viewing it -- simply select File/Save As File and store the file with the appropriate name in the include directory. YOU ARE STRONGLY ENCOURAGED TO SAVE THE EXISTING HEADER BEFORE OVERWRITING IT.

For example, to replace the header <deque> in a typical VC++ V5.0 installation, choose the directory:

c:\Program Files\DevStudio\VC\include
and save the file with the name deque. Note that some browsers insist on saving the file with the name deque.txt, in which case you will have to rename the file after saving it from the browser.

Be warned that updating a header file does not necessarily trigger a recompilation. You may have to force a rebuild to see the effect of a change.

Note also that some header-file information is captured in DLLs supplied by Microsoft. If you encounter a conflict, you must either avoid using the DLL (by linking statically) or rebuild the offending DLL. We still can supply no information on how to rebuild the standard DLLs shipped with VC++. (Microsoft insists that it's too difficult to describe.)

It is always a good idea to apply the latest Microsoft service pack to upgrade your compiler. Many problems quietly disappear when you do so. For example, you can now get V5.0 SP3 and V6.0 SP3.

DISCLAIMER
The files presented here are copyright ?1995-2000 by P.J. Plauger. All rights reserved. They are for use only in conjunction with a valid license for Microsoft Visual C++ V5.0 or V6.0. Microsoft Corporation is in no way involved with the production or release of these files. The files are offered on an ``as is'' basis. DINKUMWARE, LTD. AND P.J. PLAUGER MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY OF THESE FILES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. DINKUMWARE, LTD. AND P.J. PLAUGER SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING THESE FILES.


--------------------------------------------------------------------------------

Fix to <algorithm>
The internal template algorithm _Buffered_merge (two versions) fails to initialize local variables in two places. Change the code as indicated by the comments:

    if (_D2 < _D1)
        {_D1n = _D1 / 2, _D2n = 0;    // clear _D2n
        _Fn = _F;
        advance(_Fn, _D1n);
        _Ln = lower_bound(_M, _L, *_Fn);
        _Distance(_M, _Ln, _D2n); }
    else
        {_D1n = 0, _D2n = _D2 / 2;    // clear _D1n
        _Ln = _M;
        advance(_Ln, _D2n);
        _Fn = upper_bound(_F, _M, *_Ln);
        _Distance(_F, _Fn, _D1n); }
And for the version with predicate:

    if (_D2 < _D1)
        {_D1n = _D1 / 2, _D2n = 0;    // clear _D2n
        _Fn = _F;
        advance(_Fn, _D1n);
        _Ln = lower_bound(_M, _L, *_Fn, _P);
        _Distance(_M, _Ln, _D2n); }
    else
        {_D1n = 0, _D2n = _D2 / 2;    // clear _D1n
        _Ln = _M;
        advance(_Ln, _D2n);
        _Fn = upper_bound(_F, _M, *_Ln, _P);
        _Distance(_F, _Fn, _D1n); }
Fixes to <deque>
The header <deque> (updated 18 October 1999 to V2.33, the latest shipped version) presented here corrects a problem with the representation of the iterator that designates the end of the controlled sequence. If the sequence exactly fills the last allocated block, incrementing the iterator that designates the last element can yield a value that does not match the value returned by end(). The larger the elements stored in the container, the more likely this situation will arise.

The fix is to ensure that every iterator has just one possible representation. For added security, the ends of the container are now guarded with null map pointers. It is no longer possible to step an iterator off either end of the sequence. (Such protection is not required by the C++ Standard, but it makes for nicer failure modes in buggy code.)

Fix to <fstream>
(Added 13 October 1999.) The header <fstream> defines template class basic_filebuf (among other things. Its member function _Init contains a bug that causes files opened by name to disable buffering unnecessarily, resulting in a serious degradation of performance. Change the test:

if (_Fp != 0 && !_Closef && sizeof (_E) == 1)
to:

if (_Fp != 0 && sizeof (_E) == 1)
to eliminate this problem.

Fix to <istream>
The header <istream> contains a definition for member function basic_istream::getline. It has a lookahead problem -- typing a delimiter to end the input doesn't return control until you type yet another character. Change the code as indicated by the comment:

    else if (_C == _Di)
        {++_Chcount;
        rdbuf()->snextc();    // replace snextc with sbumpc
        break; }
Note that V6.0 replaces snextc with stossc. It is an adequate fix, but you can also apply the above patch safely.

Fix to <list>
(updated 7 July 1998) Both versions of the member function list::sort misplace elements if asked to sort a container with more than 32,768 elements. To fix the first version, change the code as indicated by the comment:

        if (_I == _MAXN)
            _A[_I].merge(_X);
    // SHOULD BE    _A[_I - 1].merge(_X);
Also change the corresponding line in the second version:

        if (_I == _MAXN)
            _A[_I].merge(_X, _Pr);
    // SHOULD BE    _A[_I - 1].merge(_X, _Pr);
You might also consider increasing _MAXN from 15 to, say 25. That way, you would have to sort a list of more than 32 million elements, instead of 32 thousand, before the performance begins to degrade.

Fix to <memory>
Template class auto_ptr creates two owners for an object if you copy an auto_ptr object back to a previous owner that still stores the same object pointer. To eliminate this problem, change the code in auto_ptr::operator= as indicated by the comment:

    else if (_Y._Owns)
        _Owns = true;    // _Owns = true, _Y.release();
Note that this template class has been redesigned more than once since this version of the library was frozen. No attempt is made here to track those changes.

Fix to <sstream>
(Added 12 November 1999.) Class basic_stringbuf grows its buffer by fixed-size increments, which can be very slow if the buffer gets very large. To grow the buffer exponentially, replace the line in basic_stringbuf::overflow that reads:

    size_t _Ns = _Os + _Alsize;
with:

    size_t _Ns = (_Os < _Alsize) ? _Os + _Alsize : 2 * _Os + 1;
Fix to <string>
The header <string> contains a definition for template function getline. It has a lookahead problem -- typing a delimiter to end the input doesn't return control until you type yet another character. Change the code as indicated by the comment:

    else if (_Tr::eq(_C, _D))
        {_Chg = true;
        _I.rdbuf()->snextc();    // replace snextc with sbumpc
        break; }
Fix to <vector>
The header <vector> sometimes fails to extend a vector properly. In two versions ofinsert, change the code as shown:

        _Destroy(_First, _Last);
        allocator.deallocate(_First, _End - _First);
        _End = _S + _N;
        _Last = _S + size() + _M;
        _First = _S; }

        _Destroy(_First, _Last);
        size_type _O = size();    // add this statement
        allocator.deallocate(_First, _End - _First);
        _End = _S + _N;
        _Last = _S + _O + _M;    // was _Last = _S + size() + _M;
        _First = _S; }
Fix to <xmemory>
Template class _Destroy has an unfortunate interaction with a bug in the VC++ compiler. It gets confused if you ask it to destroy an object of a class that defines the name _Ty. (Template class complex is one such creature.) The best workaround is to replace the template parameter _Ty with a really strange name, as in:

        // TEMPLATE FUNCTION _Destroy
template<class _Xyzzy> inline
    void _Destroy(_Xyzzy _FARQ *_P)
    {_DESTRUCTOR(_Xyzzy, _P); }
Fixes to <xstring>
The header <xstring> (original 25 May 1998) presented here corrects a problem with string assignments. Assigning a shorter sequence to an existing string can cause the old string to be copied in full to the newly allocated area, thus causing a storage overwrite, and an occasional storage leak as a result. In rarer circumstances, a string is partially altered by a replace member function before the copy on write occurs, thus causing changes to an apparently unrelated string object.

The fix is a small but significant change to the private member function _Grow. Several calls to _Freeze, to force a copy on write, are also added.

Please note that this implementation is still not as thread safe as it should be, because of the reference-counted implementation. A write to a ``copy'' of a string in one thread can confuse a read of that string in another thread, because the two still secretly share the same representation. One way to ensure that the non-const string str has a private representation is to call str.begin(). (By creating a mutable iterator into the string, you rule out sharing of representations.) Another way is to disable reference-counting altogether, making string operations thread safe. Simply change the value of _FROZEN to zero:

    enum _Mref {_FROZEN = 255};  // set to zero to disable sharing
Fix to <xtree>
The header <xtree> (original 25 June 1998) presented here eliminates all need for thread locks and corrects a number of thread-safety issues for template classes map, multimap, set, and multiset. It also solves some nasty problems with sharing these classes across DLLs. Note that no attempt has been made to retrofit the changes needed to make these template classes exception safe in the sense required by the final C++ Standard. (The headers map and set once presented here have been dropped as of 4 April 1999 -- they were effectively unchanged over the shipped versions.)

Fix to strftime.c
The Microsoft C library file strftime.c (original 28 March 2000) fails to supply locale information needed for the %X conversion specifier used by template class time_put. To fix the problem, add the missing line shown below to the function _Gettnames. Change the code from:

    s += strlen(strcpy(s, pt->ww_ldatefmt)) + 1;
    pn->ww_timefmt = s; }
to:

    s += strlen(strcpy(s, pt->ww_ldatefmt)) + 1;
    pn->ww_timefmt = s;
    strcpy(s, pt->ww_timefmt); }
NB: You need to make this change even if you licensed the v3.08 upgrade library from Dinkumware. We do not supply a replacement for it.