Not an issue. That loop is never normally exited. If `lval_eval` calls `exit(0)`, the process is terminated and memory no longer matters. How else would you do it? There are ways to read input into a pre-initialised buffer, but they're painful, because you have to check if the input was larger than the buffer and read again in a loop. Trading potential memory leaks for potential buffer overflows isn't a gain. There's nothing wrong with using GNU readline. What are you worried about? Performance? Not an issue. Dynamic memory allocation? Should be avoided when possible; not possible here. Dependencies come at a cost. There are projects for which a string library dependency is justified. I doubt a toy REPL is one of them. C strings are simple and well-understood. If you don't understand them, a project like this is a great place to learn. No code is perfect, but this looks like decent C to me.I don't think that all memory will get released properly if you will terminate this loop by C-c.
is there no other option in your code then to re-initialize variables inside a loop?
trying out The Better String Library
Erm. I was just explaining why I think the choices in the code are reasonable. Sorry if I offended you. I didn't. I disagree with your opinions, but I didn't think you're an idiot or a pedant or whatever. Maybe inexperienced, but not stupid. I dunno, my life's been super-busy, so I haven't been around as much as I'd like, but Hubski isn't Reddit. I think a lot of times comments go unseen, or people don't have anything valuable to add, so they don't. I think neither. Few things are black or white. I do think readline is simpler though, and as Dijkstra said, "Simplicity is prerequisite to reliability". Again, don't take this the wrong way, but only one of us is getting worked up. I'm going to keep posting my professional opinion on code, and I'd encourage you to do the same, and maybe we'll all learn something.how come that if I have any concern here I'm either ignored or people read my comments in a (apparently?) Comic Book Guy voice?
Comic Book Guy voice?
I'm either ignored
some think that my way is the way, other think it's atrocious abortion of a code.
Man, chill
I'd have to dig into it to be sure, but I suspect it's a false positive, depending how you define 'false positive'. So, the loop doesn't normally exit (unless one of those functions is a heinous macro). So, when you hit C-c, something, presumably `lval_eval`, calls `exit(1)`. When it does, the process immediately terminates, and the memory in `main` allocated by `readline`, `lval_read`, and `lenv_new` won't be deallocated before termination. Unequivocally. But not cleaning up everything on exit isn't really a memory leak. Any time you exit a program by calling `exit`, you're almost certainly going to leave memory unreleased. That's not really an issue. Some people don't like it, but it's not really a problem. The process terminates, the OS recaptures the memory, end of story. Agreed. Some people think you should always clean everything up. I tend to think it depends on the size of the app. It certainly makes things cleaner for bigger projects, and easier to track down real memory leaks, because Valgrind & Co don't have 'false positives'. I don't think the loop is the issue. With an `exit`, the whole program is killed. The `lenv_del` outside the loop is never called either, and `e` is also leaked. Thinking about it more, I don't think what you want is technically possible. The `lval_eval` has to take all the input, and you don't know how big the input will be. Static buffers in a loop can work for getting all the input, but some way, somehow, you have to get data of unknown length to `lval_eval`. So, you could make `lval_eval` take a fixed length and save state for a second call. But then `lval_eval` has to keep dynamic memory, because it might not be 2 buffers' worth, it might be 200. The dynamic allocation is out of the loop, but it didn't go away, it just moved somewhere else. What you really probably want is garbage collection, or C++ RAII. C just doesn't have a way to specify future deallocation. If it were me, I'd probably make `lval_eval` return an outparam signalling whether to exit, so the main loop would get the signal and `break` after freeing resources. Not a big deal for a small REPL, but certainly for a big project. Everything is relative. From an FP perspective, the `exit` is a side-effect, and this is one of countless reasons impure functions make everything harder.memory leaks are among the worst things and it should not be ignored
at the very least, is going to obfuscate debugging later on.
avoid in-loop declaration of pointers at all cost
No difference. Whether you kill the process with a few bytes of allocations, or 10Gb. In fact, AFAIK the way most operating systems work, if you allocate memory and then free it properly, the OS will still keep that memory 'allocated' to your process, because you're likely to ask for that much again. Again, talking about killing the process. While running, you're right, memory leaks are a huge deal. Especially for long-running applications and services. I think a lot of programmers fall in the same category, myself included. Analytical intelligence and social intelligence tend to have an inverse correlation. I probably didn't develop the social skills most people acquire by high school, until some years after undergrad. And I didn't learn to take things in general less seriously until my late twenties. I think that's just part of getting older, learning to get along with people, play politics. Learning to take enough enjoyment from conversations with nice people, to tolerate being nice to mean people. I'm still not where I'd like to be. I think we're all still learning. So ist das Leben.Are there any guidelines on what is considered, for example, too tasking for system to clean up?
a lot of my reading into people disagreeing with me probably stems from my background.