Re: Bug in TObjArray?

Hi Vassili,

  bounds are checked:

(proof) [395] root.exe
ROOT 5.27/05 (trunk_at_35361, Sep 17 2010, 16:11:50 on macosx64) root [0] TObjArray a
root [1] a[-1]
Error in <TObjArray::operator[]>: index -1 out of bounds (size: 16, this: 0x101e0c940)
(class TObject*)0x0
root [2] a[-1] = new TObject
Error in <TObjArray::operator[]>: index -1 out of bounds (size: 16, this: 0x101e0c940)
(class TObject*)0x1016f18b0
root [3] a.At(-2)
Error in <TObjArray::At>: index -2 out of bounds (size: 16, this: 0x101e0c940) (const class TObject*)0x0
root [4] a.At(10000)
Error in <TObjArray::At>: index 10000 out of bounds (size: 16, this: 0x101e0c940)
(const class TObject*)0x0

Cheers, Fons.

On 17/09/2010 16:21, Vassili Maroussov wrote:
> Hi Axel,
>
> I got your point... although I never thought to use TObjArray with
> "placement new" (TClonesArray seems better suited for that, since it
> provides pre-allocated memory). Now have to remember that neither
> TObjArray[] nor TObjArray.At() is checking bounds at "read access" :(
>
> Cheers,
>
> Vassili
>
> On 09/17/2010 02:40 PM, Axel Naumann wrote:
>> Hi Vassili,
>>
>> yes, that's on purpose, think of
>>
>> new (Arr[0]) TObject;
>>
>> Cheers, Axel.
>>
>>
>> Vassili Maroussov wrote on 09/17/2010 02:31 PM:
>>> Dear ROOTers,
>>>
>>> I'm wondering why TObjArray is designed in such a way that an attempt to
>>> access the [fLowerBound] element of an empty TObjArray doesn't cause any
>>> error (please see the example attached). Moreover, it has a rather
>>> unpleasant side effect: after the access GetEntriesFast() reports that
>>> the array isn't empty any more. Is it done purposely?
>>>
>>> Regards,
>>>
>>> Vassili
>>>
>

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers_at_cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640