Repository navigation
Added
ParseOptions::accept_real_without_point: a data-section real written
without the decimal point ISO 10303-21 requires before its exponent
(1E-05,-2E3,3e+2,+4E0) is read as the real it means, with the
point inserted (1.E-05), and reported as one
DiagnosticKind::RealWithoutPointwarning over the number's bytes. The
stored value carries the point, so the writer emits valid Part 21.
Incomplete numbers (1E,1E-,1EE2,.5E2) stay errors, strings are
never touched, and the header stays strict. buildingSMART's own IFC4.x
alignment test files write such reals.StepError::is_real_without_point: strict parsing refuses such a number
with this typed error, its span covering exactly the number and its
detail quoting it. Before, the error was a generic syntax error whose
span ended at theE.- Lazy decoding under options:
decode_record_with,
decode_record_borrowed_withandScan::decode_withreturn the record
exactly asparse_withreads it with the same options, plus that
record's diagnostics.decode_recordanddecode_record_borrowedstay
strict.
Changed
ParseOptions::lenient()also accepts reals without a decimal point: a
lenient parse now keeps such a record with a warning instead of skipping
it.ParseOptions::strict().on_malformed_record(OnMalformed::Skip)keeps
the old behaviour.
The common number path is unchanged; the new handling is out of line.
Measured on a 109 MB Revit IFC and a 102 MB STEP file against 0.10.0:
+0.3% and +0.6% user-space instructions for a strict parse.