<div dir="ltr">On Thu, Apr 21, 2016 at 12:55 PM, Sean McBride <<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>> wrote:<br>> On Thu, 21 Apr 2016 12:05:30 -0400, David Lonie said:<br>> >> GetBuffer() returns null, which it doesn't in 6.3.<br>> ><br>> >vtkBuffer::GetBuffer should only return NULL when there's no data in the<br>> >array, in which case the returned pointer should not be dereferenced<br>> >anyway. What is the actual error you're seeing?<br>><br>> 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.<br>><br>> So to compare, I'm now stepping through in 6.3 where GetPointer is:<br>><br>>   T* GetPointer(vtkIdType id) { return this->Array + id; }<br>><br>> here, this->Array is not null, but instead is a pointer to an empty string.<br><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Dave</div></div>