Raising exceptions halfway through a memory allocation is undefined
behavior since exceptions themselves require multiple allocations and
the allocator functions are not reentrant.
It is of course also expensive performance-wise to introduce lots of
exception-raising code everywhere since it breaks many optimisations and
bloats the code.
Finally, performing pointer arithmetic with signed integers is incorrect
for example on on a 32-bit systems that allows up to 3gb of address
space for applications (large address extensions) and unnecessary
elsewhere - broadly, stuff inside the memory allocator is generated by
the compiler or controlled by the standard library meaning that
applications should not be forced to pay this price.
If we wanted to check for overflow, the right way would be in the
initial allocation location where both the size and count of objects is
known.
The code is updated to use the same arithmetic operator style as for
refc with unchecked operations rather than disabling overflow checking
wholesale in the allocator module - there are reasons for both, but
going with the existing flow seems like an easier place to start.
(cherry picked from commit 8b9972c8b6)
* quit value gets saturated to ranges
* add documentation
* minimal changes
* refactor
* small fix
* add documentation
* fixes
* Update lib/system.nim
Co-authored-by: Juan Carlos <juancarlospaco@gmail.com>
Co-authored-by: Juan Carlos <juancarlospaco@gmail.com>
* ORC refactoring in preparation for further changes (=dispose must die)
* ORC: embrace =destroy, avoid =dispose
* ORC: no need for =dispose
* closes#18421
* ORC: prepare for another patent-pending optimization
* bugfix
* '=copy' for refs can take a cyclic parameter for more ORC optimizations
* ORC: exploit the common 'it = it.next' pattern
* can't hurt to check for nil
* use an algorithm that is not obviously broken
* restore the test case
* final cleanups for --gc:orc
