Boost logo

Boost :

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2002-07-05 05:40:45

Hi all,

I came across an interesting compiler bug recently with MSVC 6 SP5 and
version 1.27 of boost:

#include <boost/smart_ptr.hpp>

class A {};
typedef boost::shared_ptr<A> my_ptr;

A* f();

int main()
        my_ptr a;
        a = f();
        return 0;

The code should not compile (shared_ptr does not have an operator= which
takes a T*) and should not link ( f() is not defined anywhere).

But rather than rejecting it, the compiler happily allows it all, and simply
misses out the offending line. (see disassembly at the bottom). If I change
the ptr type to be auto_ptr, or scoped_ptr then the compiler correctly
rejects it.

I have tested this with boost 1.28 and the compiler correctly rejects it, so
all is well. But my company is not able at this time to move on to 1.28,
and I suspect others are in similar situations.

Whilst this is clearly a compiler bug, it is such a serious bug (and easily
brought about during migration of an app from plain pointers to
shared_ptr's) would it be possible for a warning in the documentation for
users of MSVC 6 and boost 1.27?

Apologies if this has already been discussed.



10: int main()
11: {
00401040 55 push ebp
00401041 8B EC mov ebp,esp
00401043 83 EC 4C sub esp,4Ch
00401046 53 push ebx
00401047 56 push esi
00401048 57 push edi
00401049 8D 7D B4 lea edi,[ebp-4Ch]
0040104C B9 13 00 00 00 mov ecx,13h
00401051 B8 CC CC CC CC mov eax,0CCCCCCCCh
00401056 F3 AB rep stos dword ptr [edi]
12: my_ptr a;
00401058 6A 00 push 0
0040105A 8D 4D F8 lea ecx,[ebp-8]
0040105D E8 AD FF FF FF call
@ILT+10(boost::shared_ptr<A>::shared_ptr<A>) (0040100f)
13: a = f();
14: return 0;
00401062 C7 45 F4 00 00 00 00 mov dword ptr [ebp-0Ch],0
00401069 8D 4D F8 lea ecx,[ebp-8]
0040106C E8 99 FF FF FF call
@ILT+5(boost::shared_ptr<A>::~shared_ptr<A>) (0040100a)
00401071 8B 45 F4 mov eax,dword ptr [ebp-0Ch]
15: }

Boost list run by bdawes at, gregod at, cpdaniel at, john at