I'm going to claim that the problem being solved here fundamentally comes from attempting to shoehorn early exit into an ancient codebase that wasn't designed for it, via longjmp. Exceptions can be a handy language feature, but plenty of modern code written in languages like C++ (whose exception support is often eschewed) and Go gets by without them. It just has to be written so that most functions manually propagate error codes they receive, potentially after manually unwinding some core state. C code can be written that way too: the manual cleanup that must be written then extends to mundane buffer freeing, but that's a tractable and local requirement; no need for complicated global reasoning around static buffers and custom allocation schemes.
Memory management in C programs (2014)
11–20 of 106 posts
Re: Memory management in C programs (2014)
#12This is a very interesting intro to some ways that a C program can manage memory.
Re: Memory management in C programs (2014)
#13As someone obsessed with writing C code, something just clicked. I think I understand better why there are so many JavaScript programmers, so many tools and frameworks written in and around JS every day. For me, C is the gateway to the computer. It's ubiquitous. It's deceptively simple. I can literally write anything I want in C. It's an exciting thing to have an open main.c file sitting in front of me. That must be…
As a non-C user, C was always too forboding. I wrote a bit of it, and read K&R, but places like HN bang into your head that you'll likely make a horrible screw-up writing C, your code won't be secure, and it's better not to bother. Maybe I should spend some more time with it.
It's definitely a worthwhile educational experience, even if you never write in it professionally.
If you can solve the problems in K&R, a good book to work through next is Computer Systems: A Programmer's Perspective [0].
Coursera used to have a course called The Hardware Software Interface [1] which covered the same material, but it doesn't seem to be availble right now.
[1] https://www.coursetalk.com/providers/coursera/courses/the-ha...
Re: Memory management in C programs (2014)
#14I'm going to claim that the problem being solved here fundamentally comes from attempting to shoehorn early exit into an ancient codebase that wasn't designed for it, via longjmp. Exceptions can be a handy language feature, but plenty of modern code written in languages like C++ (whose exception support is often eschewed) and Go gets by without them. It just has to be written so that most functions manually propagate…
Yeah, I'm surprised they mentioned using longjmp for "exceptions". I think that just shows the age of the nethack codebase - maybe when it was being written people were trying to find ways of incorporating those error handling ideas into C. I doubt any modern C programmers would seriously consider using it over just returning an error code.
Re: Memory management in C programs (2014)
#15Earlier quoted context omitted.
I agree completely about C being the gateway to the computer. It really is the only way to go if you want to learn real programming. That doesn't mean I'm discounting JavaScript developers, but I like C better and it's more fun.
I think you're right that C is a gateway to learning how computers work. But I think using the term "real programming" in any context is flame bait...
Sure, with C, you will learn about some "low-level" things about computers that you never will if you only program in most other languages. I am talking about things like memory, bytes, addresses, the stack, binary arithmetic, bit twiddling... But that's pretty much it. Yet, there is much more to how computers work than that, and many (far from all, though) of those things you can only get a feel for if you learn some assembly programming. From there, you will see that C is a high-level, rather abstract, programming language, if only somewhat reflective of the idea of a computer of the von Neumann type. That's all. In the end, even the "machine language", of which assembly is a human-readable representation, today is usually interpreted or otherwise translated into a "true" machine instructions that get executed by the hardware. To get but a glimpse of what is going inside a computer - still on a somewhat high level - take a look at an excellent article by Mark Smotherman at https://people.cs.clemson.edu/~mark/uprog.html. If you really want to go deeper, there are transistor-level CPU simulators that run in the browser, such as the famous "visual 6502".
Re: Memory management in C programs (2014)
#16With C, at least for me, it all starts with memory management and data. Specific use of it dictates what I'm going to do (mostly image manipulation and processing). I tend to allocate one or more big malloc buffers and manage them with TLSF. I've also looked into halloc for hierarchical allocations.
Re: Memory management in C programs (2014)
#17 case OPTTYPE_KEYMAP:
str = malloc(1 + sizeof "submenu");
strcpy(str, "submenu");
return str;
return strdup("submenu");
Re: Memory management in C programs (2014)
#18case OPTTYPE_KEYMAP: str = malloc(1 + sizeof "submenu"); strcpy(str, "submenu"); return str; There isn't a good reason for this not to be return strdup("submenu"); is there?
malloc+strcpy is standard C, strdup is not.
Re: Memory management in C programs (2014)
#19I'm going to claim that the problem being solved here fundamentally comes from attempting to shoehorn early exit into an ancient codebase that wasn't designed for it, via longjmp. Exceptions can be a handy language feature, but plenty of modern code written in languages like C++ (whose exception support is often eschewed) and Go gets by without them. It just has to be written so that most functions manually propagate…
Yeah, I'm surprised they mentioned using longjmp for "exceptions". I think that just shows the age of the nethack codebase - maybe when it was being written people were trying to find ways of incorporating those error handling ideas into C. I doubt any modern C programmers would seriously consider using it over just returning an error code.
It's a common idiom, specifically in modern C code. See "C Interfaces and Implementations", one of the best books on the subject of writing reusable C. The author dedicates an entire chapter to exception handling, with longjmp as the primarily facility for it.
Re: Memory management in C programs (2014)
#20I'm going to claim that the problem being solved here fundamentally comes from attempting to shoehorn early exit into an ancient codebase that wasn't designed for it, via longjmp. Exceptions can be a handy language feature, but plenty of modern code written in languages like C++ (whose exception support is often eschewed) and Go gets by without them. It just has to be written so that most functions manually propagate…
> plenty of modern code written in languages like C++ (whose exception support is often eschewed) and Go gets by without [exceptions].
I would not consider C++ code that eschews exceptions "modern". To eschew exceptions almost always entails giving up RAII, and if you give up RAII you've done yourself a huge disservice: you're now stuck manually managing memory and resources, and suffering all the bugs that come with that. While RAII does not outright prevent these bugs (which is one of the reasons I'm a huge fan of Rust), coding along its principles greatly reduces the risk that you will run into problems.
If you're wondering: giving up exceptions means a constructor has no way to signal failure, as the result of a ctor in C++ is always either an exception, or a constructed object. Most "no exceptions" C++ code I've seen opts to construct what I call "zombie objects"; internally, the object tracks that an error has occurred, and all uses of the real object must be first checked against that internal error flag to ensure the object isn't a zombie (or if it is, then error). The object is effectively a null pointer, and has all the trouble that entails.
(I also won't pretend that exceptions aren't without problems; in particular, the argument against them because you can't tell, at a particular point in a function's code, if an exception can occur, or where it would be caught, is completely valid, but no different in many popular languages, such as Python, C#, and in some ways, Java. However, I think the advantages of RAII — and exceptions — outweigh their disadvantages.)
> It just has to be written so that most functions manually propagate error codes they receive
When I've had to write C, I've found this to be exceptionally tedious to do correctly, and all too easy to ignore.