6 ms·

Not every string is allocated from the heap. There is no way to know if a string passed to a function, for example, came from the heap or not.

admax88q 9y ago
That's true, although there's no reason the stack allocator couldn't record this information somewhere as well. And if the memory allocator doesn't know about the string then you could just revert to the existing behaviour so you're no worse off.
- chrisseaton 9y ago
  There's more ways to allocate memory than the heap and stack.
  - stochastic_monk 9y ago
    What are you referring to? sbrk? mmap? I typically use either the heap or the stack myself.
    - timClicks 9y ago
      Static memory is at the bottom of the address space, below the heap. But that would really only be relevant in the case of string literals unless I'm mistaken.
      - unwind 9y ago
        You can have a static buffer: static char buf[128]; and use strcpy() at any point to copy into it, so I don't think statically allocated strings must be literals.
        stochastic_monk 9y ago
        There is a distinction between const and non-const static memory, though, in that the former can be stored in Read-Only Memory. Still, static memory is generally used for many fewer purposes than the stack or the heap, and if I understand correctly, sbrk is still working with the heap, just more manually.
        timClicks 9y ago
        That's right. Allocators use the sbrk and mmap to manage the heap. IIRC high performance allocators tend to use mmap exclusively.
    - MarceColl 9y ago
      Something like memory pools or manual memory management. Yes the memory pool will come from the heap or stack but the heap/stack allocator will have no idea what is going on in there.
  - adrianmonk 9y ago
    And all of them know how much memory they've allocated.
    - MarceColl 9y ago
      Yes, but unless you expose at the language level an interface for all types of allocators and enforce it then a whole lot of allocation techniques like memory pools couldn't be used with strcpy or would have to use char* type of strings again. The point is not that allocators don't know how much memory has been allocated, but that C has no idea about the underlying allocator, so it cannot ask it about the length of the string as it was proposed.
  - admax88q 9y ago
    Okay but you don't have to implement a 100% solution to make 90% of existing code much safer. How much C code is out there that only uses malloc/free? All of those programs could be made safer if the default string methods were able to prevent writing past the end of the array.
- adrianN 9y ago
  Clang offers a memory sanitizer that does a lot of extra checking. People don't ship their software with the sanitizer activated because the performance hit is nontrivial.
- xtrapolate 9y ago
  You're free to do as you please here. You don't have to use malloc()/free(), just implement your own LIBRARY_Alloc()/LIBRARY_Free()/LIBRARY_GetMemorySizeBytes() :)
Gibbon1 9y ago
However that doesn't mean that you shouldn't be able to either Would be nice to be able to tell if something is allocated on the heap or stack in a portable way. As in being able to ask if and object is thread local or not. The language and run time could support that but studiously does not. Just like the language could allow you to directly monkey with the ABI but does not.
- wruza 9y ago
  That something could be allocated by custom allocator like new or g_slice_alloc. You can monkey with the ABI as numerous FFI libraries do, but it is not portable by definition, unless you’re using, well, portable FFI library. Personally I can’t see why string, abi, etc libraries must be included. Include GLib++/GObject++ then and use its actually large ecosystem — what problem are you trying to solve by blaming low-level? That low-level is too low? Do you need high-level low-level that everyone will obey next morning? Check Java?
  - Gibbon1 9y ago
    > portable FFI library I looked into that, not available on many many platforms.

admax88q 9y ago

That's true, although there's no reason the stack allocator couldn't record this information somewhere as well. And if the memory allocator doesn't know about the string then you could just revert to the existing behaviour so you're no worse off.

chrisseaton 9y ago
There's more ways to allocate memory than the heap and stack.
- stochastic_monk 9y ago
  What are you referring to? sbrk? mmap? I typically use either the heap or the stack myself.
  - timClicks 9y ago
    Static memory is at the bottom of the address space, below the heap. But that would really only be relevant in the case of string literals unless I'm mistaken.
    - unwind 9y ago
      You can have a static buffer: static char buf[128]; and use strcpy() at any point to copy into it, so I don't think statically allocated strings must be literals.
      - stochastic_monk 9y ago
        There is a distinction between const and non-const static memory, though, in that the former can be stored in Read-Only Memory. Still, static memory is generally used for many fewer purposes than the stack or the heap, and if I understand correctly, sbrk is still working with the heap, just more manually.
        timClicks 9y ago
        That's right. Allocators use the sbrk and mmap to manage the heap. IIRC high performance allocators tend to use mmap exclusively.
  - MarceColl 9y ago
    Something like memory pools or manual memory management. Yes the memory pool will come from the heap or stack but the heap/stack allocator will have no idea what is going on in there.
- adrianmonk 9y ago
  And all of them know how much memory they've allocated.
  - MarceColl 9y ago
    Yes, but unless you expose at the language level an interface for all types of allocators and enforce it then a whole lot of allocation techniques like memory pools couldn't be used with strcpy or would have to use char* type of strings again. The point is not that allocators don't know how much memory has been allocated, but that C has no idea about the underlying allocator, so it cannot ask it about the length of the string as it was proposed.
- admax88q 9y ago
  Okay but you don't have to implement a 100% solution to make 90% of existing code much safer. How much C code is out there that only uses malloc/free? All of those programs could be made safer if the default string methods were able to prevent writing past the end of the array.
adrianN 9y ago
Clang offers a memory sanitizer that does a lot of extra checking. People don't ship their software with the sanitizer activated because the performance hit is nontrivial.
xtrapolate 9y ago
You're free to do as you please here. You don't have to use malloc()/free(), just implement your own LIBRARY_Alloc()/LIBRARY_Free()/LIBRARY_GetMemorySizeBytes() :)

Gibbon1 9y ago

However that doesn't mean that you shouldn't be able to either Would be nice to be able to tell if something is allocated on the heap or stack in a portable way. As in being able to ask if and object is thread local or not. The language and run time could support that but studiously does not. Just like the language could allow you to directly monkey with the ABI but does not.

wruza 9y ago
That something could be allocated by custom allocator like new or g_slice_alloc. You can monkey with the ABI as numerous FFI libraries do, but it is not portable by definition, unless you’re using, well, portable FFI library. Personally I can’t see why string, abi, etc libraries must be included. Include GLib++/GObject++ then and use its actually large ecosystem — what problem are you trying to solve by blaming low-level? That low-level is too low? Do you need high-level low-level that everyone will obey next morning? Check Java?
- Gibbon1 9y ago
  > portable FFI library I looked into that, not available on many many platforms.