~sircmpwn added harec 3 years ago

~ecs 3 years ago

Another option is to have projects which want -Fstrictoom instead not provide rt::malloc and rt::ensure, opting to provide their allocator somewhere else - say, mem::vmalloc. This way, any builtins which would abort on allocation failure would cause link-time errors since they use rt::malloc/rt::ensure.

This wouldn't really work for non-freestanding code, but I can't think of a scenario in which a hosted program would want -Fstrictoom.

~sircmpwn 3 years ago

I don't like that approach because alloc provides strong typing and initialization guarantees that a call to rt::vmalloc(n: size) nullable *void would not.

~sircmpwn 3 years ago

Oh, and -Fstrictoom can give better error messages than a linker error would.

~autumnull 1 year, 9 months ago

this issue would likely be addressed by a nomem builtin: https://lists.sr.ht/~sircmpwn/hare-dev/%3C09e046d7-1e38-1362-4870-1448781f956c%40posteo.net%3E

~sebsite REPORTED CLOSED 1 year, 8 months ago

Closing this since the current plan is to make handling allocation failure mandatory, so a flag isn't necessary