Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PointSet::SetPoints(PointsVectorContainer *) overload leads to undefined behavior #4848

Open
N-Dekker opened this issue Sep 13, 2024 · 3 comments
Assignees
Labels
type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances

Comments

@N-Dekker
Copy link
Contributor

Description

PointSet::SetPoints(PointsVectorContainer * points) internally casts its argument to a PointsContainer *:

auto * pointsPtr = reinterpret_cast<PointsContainer *>(points);

This leads to undefined behavior, when the PointsVectorContainer object is being used as a PointsContainer object.

Steps to Reproduce

The test code already has undefined behavior, even if it might just work on the currently tested platforms:

// Insert the points using SetPointArray.
PointsVectorContainerPointer pointsArray = PointsVectorContainer::New();
// Test for in-compatible input array dimension
pointsArray->InsertElement(0, 1.0);
ITK_TRY_EXPECT_EXCEPTION(pset->SetPoints(pointsArray));
pointsArray->Reserve(numOfPoints * pointDimension);
int index = 0;
for (int i = 0; i < numOfPoints; ++i)
{
pointsArray->SetElement(index++, 1.0);
pointsArray->SetElement(index++, 2.0);
pointsArray->SetElement(index++, 3.0);
}
pset->SetPoints(pointsArray);
// Check the count of points after insertion using SetPoints.
pointsArrayAfter = pset->GetPoints();
if (static_cast<int>(pointsArrayAfter->Size()) != numOfPoints)
{
std::cerr << "Mismatch in count after inserting points." << std::endl;
return EXIT_FAILURE;
}

Versions

Additional Information

Discussed before at #3154 (comment), with @PranjalSahu

@N-Dekker N-Dekker added the type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances label Sep 13, 2024
N-Dekker added a commit to N-Dekker/ITK that referenced this issue Sep 17, 2024
Aims to mitigate issue InsightSoftwareConsortium#4848
"`PointSet::SetPoints(PointsVectorContainer *)` overload leads to undefined behavior"
dzenanz pushed a commit that referenced this issue Sep 20, 2024
Aims to mitigate issue #4848
"`PointSet::SetPoints(PointsVectorContainer *)` overload leads to undefined behavior"
N-Dekker added a commit to N-Dekker/ITK that referenced this issue Oct 21, 2024
When the points are specified by a flat VectorContainer of coordinates, passing
those points to `SetPoints` may lead to undefined behavior.
`SetPointsByCoordinates` is in that case preferred.

- Partially addresses issue InsightSoftwareConsortium#4848
"`PointSet::SetPoints(PointsVectorContainer *)` overload leads to undefined behavior"
N-Dekker added a commit to N-Dekker/ITK that referenced this issue Oct 24, 2024
The SetPoints calls in two serialization tests appear unsafe, as was reported by
issue InsightSoftwareConsortium#4848
"`PointSet::SetPoints(PointsVectorContainer *)` overload leads to undefined behavior".

With this commit, those tests try both using SetPointsByCoordinates and using
the unsafe SetPoints overload.
@ebrahimebrahim
Copy link
Contributor

Note that the problem has moved to here since #4867:

// Note: this cast is unsafe. It may lead to undefined behavior.
auto * pointsPtr = reinterpret_cast<PointsContainer *>(points);

@N-Dekker
Copy link
Contributor Author

Would it be OK if we would just deprecate, and eventually remove this particular SetPoints(PointsVectorContainer *) overload? @PranjalSahu What do you think?

@PranjalSahu
Copy link
Contributor

Yes, it can be deprecated. But for the future, we should think of a way for Python to allow direct point setting without creating a new copy. Because there are use cases where the meshes can be in GB size and for performing some simple filtering, a new copy would be too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:Bug Inconsistencies or issues which will cause an incorrect result under some or all circumstances
Projects
None yet
Development

No branches or pull requests

3 participants