mirror of
https://github.com/IfcOpenShell/IfcOpenShell.git
synced 2026-08-18 03:19:53 +00:00
ifcparse: widen all integer attribute types to int64_t for consistency
Follow-up to the scalar-only fix in #8754, per aothms's direct request on that PR ("Please do make all int types consistent") and his own original 2023 design intent on issue #3058 ("make all integers (incl. schema namespaces) an int64_t"). Widens the remaining inconsistent spots now that compatibility isn't a constraint on this v0.9 branch: - Integer aggregates (IfcTriangulatedFaceSet.CoordIndex and similar List<int> attributes), including the SWIG to_vec_int/to_vec_vec_int helpers, which previously silently truncated via static_cast<int> on the Python-set path - the same bug class as the original scalar issue. - The schema code generator (express/mapping.py's integer type mapping), and all 12 generated schema header/source pairs regenerated to match, so every schema-typed getter/setter (e.g. IfcOwnerHistory::CreationDate) is int64_t end to end, not just the dynamic attribute-value path. Instance/reference identifiers (STEP #123 ids) are deliberately left at 32-bit: they're a file-local index into internal maps, not an EXPRESS domain value an application chooses, and no realistic STEP file has billions of entities. The lexer's Token_IDENTIFIER parsing still funnels through a 32-bit int for this reason - flagged as a known, low-risk gap rather than fixed, since fixing it would mean touching indexing/hashing code for no realistic benefit. Verified: original PR's round-trip tests extended with aggregate cases (IfcTriangulatedFaceSet.CoordIndex, InnerCoordIndices) at 64-bit boundary values, in memory and through STEP text, IFC2X3 and IFC4. A standalone C++ program exercising the generated schema API directly (Ifc4::IfcOwnerHistory ::setCreationDate/CreationDate, IfcTriangulatedFaceSet::setCoordIndex/ CoordIndex) confirms int64_t end to end, bypassing SWIG. Full build (BUILD_IFCGEOM, WITH_OPENCASCADE, BUILD_IFCPYTHON, IFC2X3+IFC4) clean. test/util/test_attribute.py and test_file.py pass unchanged. This contribution was produced with the assistance of an AI coding tool.
This commit is contained in:
committed by
Thomas Krijnen
parent
d5076bded3
commit
f23db9440f
@@ -701,15 +701,15 @@ private:
|
||||
return fast; // new ref
|
||||
};
|
||||
|
||||
auto to_vec_int = [&](PyObject* o) -> std::vector<int> {
|
||||
auto to_vec_int = [&](PyObject* o) -> std::vector<int64_t> {
|
||||
PyObject* fast = seq_fast(o);
|
||||
Py_ssize_t n = PySequence_Fast_GET_SIZE(fast);
|
||||
PyObject** items = PySequence_Fast_ITEMS(fast);
|
||||
|
||||
std::vector<int> out;
|
||||
std::vector<int64_t> out;
|
||||
out.reserve(static_cast<size_t>(n));
|
||||
for (Py_ssize_t k = 0; k < n; ++k) {
|
||||
out.push_back(static_cast<int>(to_index_long(items[k])));
|
||||
out.push_back(static_cast<int64_t>(to_index_i64(items[k])));
|
||||
}
|
||||
|
||||
Py_DECREF(fast);
|
||||
@@ -784,12 +784,12 @@ private:
|
||||
return out;
|
||||
};
|
||||
|
||||
auto to_vec_vec_int = [&](PyObject* o) -> std::vector<std::vector<int>> {
|
||||
auto to_vec_vec_int = [&](PyObject* o) -> std::vector<std::vector<int64_t>> {
|
||||
PyObject* fast = seq_fast(o);
|
||||
Py_ssize_t n = PySequence_Fast_GET_SIZE(fast);
|
||||
PyObject** items = PySequence_Fast_ITEMS(fast);
|
||||
|
||||
std::vector<std::vector<int>> out;
|
||||
std::vector<std::vector<int64_t>> out;
|
||||
out.reserve(static_cast<size_t>(n));
|
||||
for (Py_ssize_t k = 0; k < n; ++k) {
|
||||
out.push_back(to_vec_int(items[k]));
|
||||
|
||||
Reference in New Issue
Block a user