3 ms·

> it's a bunch of C with obvious memory leaks (remember, if theres a dup in that function name, it's gonna allocate memory) That's only really an issue if some

by pedrocr 12y ago

> it's a bunch of C with obvious memory leaks (remember, if theres a dup in that function name, it's gonna allocate memory) That's only really an issue if someone ever turns this into a library and calls it from long-running code. As a command line utility the small amounts of memory that are leaked don't ammount to too much waste and everything gets reclaimed on exit.

enqk 12y ago
there's something to be said about the elegance of short-running C programs with no deallocation, using the OS to properly relinquish memory
revelation 12y ago
I don't trust someone that can't get memory leaks in a simple utility function right to get the big, big things with writing software in C correct. This is Poetterings code after all, and he had his fingers in more than just command line utilities when it comes to systemd. Writing this kind of software in C requires serious discipline and religious use of valgrind.
- tree_of_item 12y ago
  Isn't the point that it's not a leak if the program exits quickly?
  - jacquesm 12y ago
    If you can't be trusted to get the bookkeeping right what makes you think the rest of the program is solid? Being able to manage your allocation is a pretty good sign that a C programmer knows what he's doing. Relying on 'exit' to free your memory is backporting the web mentality to unix land, it just simply doesn't work that way. There is no different attitude when you write a long running daemon versus a utility program because for all you know your utility program code will be re-purposed to become part of a longer running daemon. So you write your code in as clean a manner as possible and balance your allocs/frees and make sure that you don't have any latent buffer overflows which you may not care about today because of the context your code executes in today because tomorrow that context of execution might change and then we're looking at yet another exploit.
    - digi_owl 12y ago
      > Relying on 'exit' to free your memory is backporting the web mentality to unix land A very fitting description of systemd as a whole.
  - DougBTX 12y ago
    Cleaning up by exiting can be much faster too, eg, https://lists.gnu.org/archive/html/coreutils/2014-08/msg00012.html https://lists.gnu.org/archive/html/coreutils/2014-08/msg0001...
- jjoonathan 12y ago
  "Leak everything" is a valid memory management model if you can put bounds on runtime, etc. Seeing it in the wild isn't a reason to conclude that > someone ... can't get memory leaks in a simple utility function right because in a simple one-off utility it is right. Potterings didn't write these utilities to prove that he knew how to refcount.
  - revelation 12y ago
    The point has been made elsewhere already, but I'll mention it again: because theres no guarantee this code will stay in a simple command line utility. At some point someone may come along and refactor this Docker import code into a library or something bigger.

by pedrocr 12y ago

enqk 12y ago

there's something to be said about the elegance of short-running C programs with no deallocation, using the OS to properly relinquish memory

revelation 12y ago

I don't trust someone that can't get memory leaks in a simple utility function right to get the big, big things with writing software in C correct. This is Poetterings code after all, and he had his fingers in more than just command line utilities when it comes to systemd. Writing this kind of software in C requires serious discipline and religious use of valgrind.

tree_of_item 12y ago
Isn't the point that it's not a leak if the program exits quickly?
- jacquesm 12y ago
  If you can't be trusted to get the bookkeeping right what makes you think the rest of the program is solid? Being able to manage your allocation is a pretty good sign that a C programmer knows what he's doing. Relying on 'exit' to free your memory is backporting the web mentality to unix land, it just simply doesn't work that way. There is no different attitude when you write a long running daemon versus a utility program because for all you know your utility program code will be re-purposed to become part of a longer running daemon. So you write your code in as clean a manner as possible and balance your allocs/frees and make sure that you don't have any latent buffer overflows which you may not care about today because of the context your code executes in today because tomorrow that context of execution might change and then we're looking at yet another exploit.
  - digi_owl 12y ago
    > Relying on 'exit' to free your memory is backporting the web mentality to unix land A very fitting description of systemd as a whole.
- DougBTX 12y ago
  Cleaning up by exiting can be much faster too, eg, https://lists.gnu.org/archive/html/coreutils/2014-08/msg00012.html https://lists.gnu.org/archive/html/coreutils/2014-08/msg0001...
jjoonathan 12y ago
"Leak everything" is a valid memory management model if you can put bounds on runtime, etc. Seeing it in the wild isn't a reason to conclude that > someone ... can't get memory leaks in a simple utility function right because in a simple one-off utility it is right. Potterings didn't write these utilities to prove that he knew how to refcount.
- revelation 12y ago
  The point has been made elsewhere already, but I'll mention it again: because theres no guarantee this code will stay in a simple command line utility. At some point someone may come along and refactor this Docker import code into a library or something bigger.