4 ms·

> Every allocation must be checked at the point of allocation, which is "the default" C doesn't force you to check the allocation at all. The default behavior

by gpm 10mo ago

> Every allocation must be checked at the point of allocation, which is "the default" C doesn't force you to check the allocation at all. The default behavior is to simply invoke undefined behavior the first time you use the returned allocation if it failed. In practice I've found most people write their own wrappers around malloc that at least crash - for example: https://docs.gtk.org/glib/memory.html https://docs.gtk.org/glib/memory.html PS. The current default in rust to print something and then abort the program, not panic (i.e. not throw an exception). Though the standard library reserves the right to change that to a panic in the future.

lelanthran 10mo ago
> C doesn't force you to check the allocation at all. No one ever claimed it did; I said, and still do, that the in C, at any rate, the default is to check the returned value from memory allocations. And, that is true. The default in other language is not to recover.
- gpm 10mo ago
  > > C doesn't force you to check the allocation at all. > No one ever claimed it did; You specifically said > Every allocation must be checked at the point of allocation ... > the default is to check the returned value from memory allocations. Default has a meaning, and it's what happens if you don't explicitly choose to do something else. In libc - this is to invoke undefined behavior if the user uses the allocation. In glib - the library that underpins half the linux desktop - this is to crash. This is an approach I've seen elsewhere as well to the point where I'm comfortable calling it "default" in the sense that people change their default behavior to it. Nowhere that I've ever seen, in C, is it to make the user handle the error. I assume there are projects with santizers that do do that, I haven't worked on them, and they certainly don't make up the majority.
  - lelanthran 10mo ago
    > Default has a meaning, and it's what happens if you don't explicitly choose to do something else. It also has the meaning of doing the common thing: https://www.merriam-webster.com/dictionary/default https://www.merriam-webster.com/dictionary/default > : a selection made usually automatically or without active consideration See that "without active consideration" there? The default usage of malloc includes, whether you want to acknowledge it or not, checking the returned value. C doesn't have anything done automatically, so I am wondering why you would choose to think that by "default" one would mean that something automatically gets done.
    - gpm 10mo ago
      I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Of course things do happen automatically all the time in C, like bumping the stack pointer (another case of unhandled OOM) and decrementing it after the fact. And pushing return addresses - and returning at the end of functions. And so on. "Ubiquitous" is a different word than default, checking the return code of malloc isn't even that. As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. And it doesn't reliably check the return code. For example: https://github.com/PipeWire/pipewire/blob/6ed964546586e809f72d4668268b09f47987b080/pipewire-jack/src/metadata.c#L314 https://github.com/PipeWire/pipewire/blob/6ed964546586e809f7... And again, this isn't cherry picked, this is just "the last popular open source C code base I've looked at". This is the common case in C. Either you wrap malloc to crash, or you just accept undefined behavior if malloc fails. It is the rare project that doesn't do one of those two.
      - lelanthran 10mo ago
        > I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Right. But this is what you initially responded to: > You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures? > As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. Correct. That does not mean that the default way of writing allocation in C is anything other than what I said. Do programmers make mistakes? Sure. But that's not what asked - what was asked is how do you handle memory errors gracefully, and I pointed out that, in idiomatic C, handling memory errors gracefully is the default way of handling memory errors. That is not the case for other languages.
        gpm 10mo ago
        > How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures? I think you might want to reread the line you quoted directly above this, That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C". This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction of projects allocator wrappers). Not "handling OOM gracefully" - i.e. handling OOM errors.

by gpm 10mo ago

lelanthran 10mo ago

> C doesn't force you to check the allocation at all. No one ever claimed it did; I said, and still do, that the in C, at any rate, the default is to check the returned value from memory allocations. And, that is true. The default in other language is not to recover.

gpm 10mo ago
> > C doesn't force you to check the allocation at all. > No one ever claimed it did; You specifically said > Every allocation must be checked at the point of allocation ... > the default is to check the returned value from memory allocations. Default has a meaning, and it's what happens if you don't explicitly choose to do something else. In libc - this is to invoke undefined behavior if the user uses the allocation. In glib - the library that underpins half the linux desktop - this is to crash. This is an approach I've seen elsewhere as well to the point where I'm comfortable calling it "default" in the sense that people change their default behavior to it. Nowhere that I've ever seen, in C, is it to make the user handle the error. I assume there are projects with santizers that do do that, I haven't worked on them, and they certainly don't make up the majority.
- lelanthran 10mo ago
  > Default has a meaning, and it's what happens if you don't explicitly choose to do something else. It also has the meaning of doing the common thing: https://www.merriam-webster.com/dictionary/default https://www.merriam-webster.com/dictionary/default > : a selection made usually automatically or without active consideration See that "without active consideration" there? The default usage of malloc includes, whether you want to acknowledge it or not, checking the returned value. C doesn't have anything done automatically, so I am wondering why you would choose to think that by "default" one would mean that something automatically gets done.
  - gpm 10mo ago
    I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Of course things do happen automatically all the time in C, like bumping the stack pointer (another case of unhandled OOM) and decrementing it after the fact. And pushing return addresses - and returning at the end of functions. And so on. "Ubiquitous" is a different word than default, checking the return code of malloc isn't even that. As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. And it doesn't reliably check the return code. For example: https://github.com/PipeWire/pipewire/blob/6ed964546586e809f72d4668268b09f47987b080/pipewire-jack/src/metadata.c#L314 https://github.com/PipeWire/pipewire/blob/6ed964546586e809f7... And again, this isn't cherry picked, this is just "the last popular open source C code base I've looked at". This is the common case in C. Either you wrap malloc to crash, or you just accept undefined behavior if malloc fails. It is the rare project that doesn't do one of those two.
    - lelanthran 10mo ago
      > I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Right. But this is what you initially responded to: > You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures? > As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. Correct. That does not mean that the default way of writing allocation in C is anything other than what I said. Do programmers make mistakes? Sure. But that's not what asked - what was asked is how do you handle memory errors gracefully, and I pointed out that, in idiomatic C, handling memory errors gracefully is the default way of handling memory errors. That is not the case for other languages.
      - gpm 10mo ago
        > How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures? I think you might want to reread the line you quoted directly above this, That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C". This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction of projects allocator wrappers). Not "handling OOM gracefully" - i.e. handling OOM errors.