forked from 1b-agent/opencadstudio-upstream
Karim Jerbi
8b5e5a3408
Bug: EMF polyline/polygon records carry a ring count as a raw u32. pts16/pts32 did Vec::with_capacity(count) on it directly - a crafted 4294967295 pre-allocates about 4 billion slots and the allocator aborts. The existing total > 400_000 guard only checked the sum of ring counts, never an individual ring's vector. Reproduce: 1. Craft an EMF whose POLYPOLYLINE/POLYGON count is 0xFFFFFFFF. 2. Attach/import it. 3. Before: "pre-allocated 4294967295 slots" then memory allocation failed (multi-GB pre-allocation). 4. After: the vector is sized from the bytes actually present in the record; the parse consumes what the record holds. Fix: pts16/pts32 size their capacity as count.min(available_bytes / point_size) - the record's own remaining length is the ceiling, so allocation is O(record). The iteration logic is untouched: it stops when the bytes run out, so output for valid records is byte-identical (the guard is a pure allocation bound). Tests: the u32::MAX ring no longer pre-allocates; valid single- and multi-ring records still parse.