Serious bug in FdoPtr<T> copy ctor (patch attached)

[Kosta]

If you assign an FdoPtr<T> object "t" to a new FdoPtr<U> object "u" where U is a base class of T the ref count is not increased. Example:

FdoPtr<FdoIPolygon> poly = FdoFgfGeometryFactory::GetInstance()
    ->CreatePolygon(outerRing, innerRings);
// ref count of poly == 1

FdoPtr<FdoIGeometry> geom = poly;
// ref count of poly (and geom) still == 1

If both pointers go out of scope the pointed to object gets deleted by the first FdoPtr-dtor and the second pointer holds a dangling pointer resulting in a crash during destruction...

The problem is that FdoPtr<T> only defines a copy ctor for type T. So during construction of the "geom" pointer, first "FdoPtr<FdoIPolygon>::operator FdoIPolygon*()" is called on the "poly" pointer and the resulting plain "FdoIPolygon*" pointer is feed into "FdoPtr<FdoIGeometry>::FdoPtr(FdoIGeometry* t)"; but this ctor does not increase the reference count of the pointed to object!

Proposed patch:

Change the existing impl of the copy ctor from:

    /// \brief
    /// FdoPtr copy constructor. Wraps a new FdoPtr around the object
    /// referenced by lp.
    /// 
    /// \param lp 
    /// Input the FdoPtr to copy from.
    /// 
    /// \return
    /// Returns a FdoPtr
    /// 
    /// \note
    /// This operator adds a reference on the object.
    FdoPtr(const FdoPtr<T>& lp) throw()
    {
        p = lp.p;
        if (p != NULL)
            p->AddRef();
    }

into:

    /// \brief
    /// FdoPtr copy constructor. Wraps a new FdoPtr around the object
    /// referenced by lp. Type U must be convertible to type T.     <<<<< here
    /// 
    /// \param lp 
    /// Input the FdoPtr to copy from.
    /// 
    /// \return
    /// Returns a FdoPtr
    /// 
    /// \note
    /// This operator adds a reference on the object.
    template <class U>                                              <<<<< here
    FdoPtr(const FdoPtr<U>& lp) throw()                             <<<<< here
    {
        p = lp.p;
        if (p != NULL)
            p->AddRef();
    }

[Kosta]

Correction: at least for VS2005 there must be both ctors available...

[gregboone]

The FDO teams prefers not too change this behaviour in 3.4.0. It is a bit late in the development cycle and we cannot be sure of the resulting impact on all our provider and application implemnetations. I am aware that workaround have been made in application due to this issue and there is not enough time to identify and resolve all those at this time.

Defer to 3.5 or 4.0.

[gregboone]

Instead of closing this issue, let's defer this to a future release. i.e. FDO 4.0

[Kosta]

Just a short note: to spot the affected source code lines, it should be enough to put the proposed additional template ctor into the private section of the class declaration and do a recompile...

[traianstanev]

I'm picking this up, I intend to fix it together with the removal of the null check from the operator->.