[vtk-developers] vtkMINCImageAttributes regression in master vs 6.3, related to new vtkDataArray changes?

[David Lonie]

On Thu, Apr 21, 2016 at 12:55 PM, Sean McBride <sean at rogue-research.com>
wrote:
> On Thu, 21 Apr 2016 12:05:30 -0400, David Lonie said:
> >> GetBuffer() returns null, which it doesn't in 6.3.
> >
> >vtkBuffer::GetBuffer should only return NULL when there's no data in the
> >array, in which case the returned pointer should not be dereferenced
> >anyway. What is the actual error you're seeing?
>
> Superficially, my problem is that in VTK 6.3 and earlier, with every MINC
file we have in our testing collection,
vtkMINCImageAttributes::GetAttributeValueAsString() never returns null, now
with git master it sometimes does.  My code is assuming (perhaps
incorrectly?) that null is never returned, and I unconditionally
dereference it and thus now crash.
>
> So to compare, I'm now stepping through in 6.3 where GetPointer is:
>
>   T* GetPointer(vtkIdType id) { return this->Array + id; }
>
> here, this->Array is not null, but instead is a pointer to an empty
string.

I'd say that the issue is the unconditional dereference. We've never
guaranteed that the returned pointer would not be null, and dereferencing
it when the array is empty is asking for trouble and bad design IMO.

I don't think we can even change it to always return a valid pointer.
vtkAbstractArray::Initialize() is documented to 'release storage', which to
me means that there should not be any memory allocated to the array
afterwards. In this case, NULL is the only logical value that can be
returned.

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160421/344ae6d0/attachment.html>