Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory management in C programs (2014)

nethack4.org

Post reply on HN
Print view View original

51–60 of 106 posts

Re: Memory management in C programs (2014)

#51

Post by PeCaN »

comex wrote: post #45
PeCaN wrote: post #42

Earlier quoted context omitted.

You can't really tell if the stack overflowed in a constructor though, plus that will essentially /never/ happen, so I think it's okay to exclude stack overflows when creating stack allocated objects as failure conditions. In that case no, a lot of constructors won't be able to fail.

Any function can overflow the stack. If the object is constructed on the heap, 'new' can fail but will always throw an exception; if you aren't using exceptions it will just crash the process.

Yeah. That's why I don't say it's a failure condition for a stack-allocated object to overflow the stack. Notice my parent comment said:

> Constructors are resource allocation, so they can always fail.

Which is false.

Re: Memory management in C programs (2014)

#52

Post by michael_h »

theseoafs wrote: post #50
deathanatos wrote: post #21

Earlier quoted context omitted.

While I agree, strdup is POSIX. In the exceedingly rare event that you're on a system without it, it's simple enough to roll your own. (And if this occurred more than a couple of times, I'd roll my own anyways to keep the code obvious.)

In the exceedingly rare event that you need to target Windows?

#define strdup _strdup

Re: Memory management in C programs (2014)

#53

Post by adrianratnapala »

comex wrote: post #11

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…

I wrote a C helper library that does poor-man's exceptions using setjmp/longjmp https://github.com/adrianratnapala/elm0.

Partly because of the malloc/free issue, you don't just "throw and forget" like with real exceptions. Instead you jump a short way up the stack, using it as an extra mechanism for error handling inside a module -- living side by side with error returns.

And I found myself using the mechanism quite a lot. To the point where writing a new error-returns based function gave me that itch where I felt this is mistake and I would end up refactoring to the TRY mechanism anyway.

Re: Memory management in C programs (2014)

#54

Post by Too »

kabdib wrote: post #32
deathanatos wrote: post #20

Earlier quoted context omitted.

> 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…

I've not seen a large production C++ code base that did anything with exceptions other than to catch them, record some debug information and restart. This is especially true when third party code is involved. C++ is hard enough to get right without exceptions; dealing with failure in bodies of code that you didn't write and maybe don't have control over (or even source code of) is death on wheels. If that means the c…

If you have a server that should process 100000 requests and processing one of them happen to throw an exception, it's very easy to just wrap request->process() with try catch and continue processing the rest of the requests.

You can also use it to recover parts of the processing with sane defaults. String parse integer exception? Use constant 0 instead if that makes sense, etc etc.

I don't see why people make exceptions in c++ into a big deal and a big mystery, in other languages people just use them, the only caveat in c++ is throwing in destructors but that's easy to remember. In one place I worked they had meetings for over a week to discuss whether it was ok or not to throw exceptions in a constructor or not T_T.

Re: Memory management in C programs (2014)

#55

Post by warmwaffles »

gp7 wrote: post #48

In my opinion, writing code that consists of malloc/free pairs is inviting all the problems RAII and garbage collectors were designed to solve and which rust can now statically check for correctness. So that's basically it: at this point, I don't use the heap to manage memory in C, because if I did I'd instead use either rust or, more likely, a garbage collected language. The fact is, despite going out of their way t…

Yes because pretending it does not exist and not understanding how things worked prior to rust is totally realistic.

Re: Memory management in C programs (2014)

#56

Post by Ace17 »

cmrdporcupine wrote: post #36
deathanatos wrote: post #20

Earlier quoted context omitted.

> 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…

I don't think it's a secret that Google's C++ code base (very large and growing) does not use exceptions. And since starting there I have not missed them. Exceptions make execution flow hard to reason about. And RAII is most certainly still a thing without exceptions. There's lots of other ways to unwind the stack.

Google is an example that writing production code that doesn't use exceptions is possible, not that this is the right thing to do.

They said that their decision was primarily legacy-motivated (in short, they were fearing that introducing exceptions in a non-RAII codebase would lead us to a long period of instability).

I'll add that in some situations (e.g when freeing resources) the control flow gets very convoluted, and you don't want to deal with directly. See: Andrei Alexandrescu - Declarative Control Flow ( https://www.youtube.com/watch?v=WjTrfoiB0MQ )

Re: Memory management in C programs (2014)

#57

Post by _cbsz »

deathanatos wrote: post #21
vinkelhake wrote: post #18

Earlier quoted context omitted.

malloc+strcpy is standard C, strdup is not.

While I agree, strdup is POSIX. In the exceedingly rare event that you're on a system without it, it's simple enough to roll your own. (And if this occurred more than a couple of times, I'd roll my own anyways to keep the code obvious.)

Nethack does have a lot of ports to weird systems (and compilers that might not special-case strdup on a string literal to avoid the strlen, which I didn't think of when I brought this up in the first place), so this seems like a fair enough reason to me.

Re: Memory management in C programs (2014)

#58

Post by adrianratnapala »

EE84M3i wrote: post #39
userbinator wrote: post #22

Earlier quoted context omitted.

And above us is probably FORTRAN and above them is probably COBOL. Actually, I think assembly language would probably be the next age "peak". If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense. The effect is weaker, but still there in the other direction. (FYI, FORTRAN predates COBOL by a few years.)

> If you know Asm you'll be far better at C; things like pointers and indirection immediately make sense. A lot of recent issues with compilers "introducing security issues" has come from this sort of understanding of C (overflows, other undefined behavior, etc). The places where C differs from just writing the assembly yourself are really really hard.

And this is generally about compilers behaving badly.

Some languages do a good job of creating an abstracted universe above the hardware that plays by its own rules. This allows the language/runtime to map programming constructs to hardware behaviour in highly inventive ways.

C never was such a language, it's hardware abstractions are -- by design -- as leak-free as a fishnet. And yet compiler writers feel they need to get creative.

Re: Memory management in C programs (2014)

#59

Post by coroutines »

sdegutis wrote: post #23
coroutines wrote: post #8

Earlier quoted context omitted.

I used to write C but now I do Coffeescript/JS. When I was just starting in C (as a teenager) I'd get really excited to learn the GNU's C standard library. I wanted to know how to make better and better console applications and networking applications. It felt like there was a huge learning curve to using graphics toolkits. Now that I do JS I feel like Web APIs are the new "C standard library". I can make console or…

It depends on what kind of programs you like to write. Personally I like to write things like programming languages or VT100-based text editors. And I like the added challenges that C presents, especially related to data modeling, memory management, lack of first-class functions, etc. So C is a natural choice for me, whereas JS adds little to no value, and actually takes away the challenge.

I hate installing things. :x I get pretty turned on by offering up something like Google Sheets as a webapp that installs and is usable in seconds over the Internet. I used to really love Lua but even though it was

Re: Memory management in C programs (2014)

#60

Post by niccaluim »

deathanatos wrote: post #20
comex wrote: post #11

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…

> 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…

>> 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.

Indeed. I write Go all day and I type "if err != nil { return nil, err }" so often I could scream.

Post reply on HN