Comment by kragen | Hacker News Reader

Comment by kragen | Hacker News Reader

In the blog post, he links to this Slashdot comment about circle-drawing at Apple on the Macintosh project here: http://apple.slashdot.org/comments.pl?sid=2462124&cid=37...

Which links to http://www.folklore.org/StoryView.py?project=Macintosh&s..., which talks a little bit about algorithms for drawing circles, ellipses, and RoundRects, and in particular what was used in QuickDraw.

QuickDraw source code is available at http://www.computerhistory.org/highlights/macpaint/ and I've posted what I think is the relevant file at https://gist.github.com/1287861. I think the relevant routine is BumpOval, starting around line 1000. But I don't understand it at all, partly because it's been 18 years since I looked at 68000 assembly. Can anyone help explain what's going on in there? I'd like to know if the algorithm being used there is the same one in Mukund's awesome blog post.

One bug: Mukund, if you're going to call malloc() without checking its return value, use xmalloc()! It's like five lines of code.

I don't know what the deal is on Linux, but in professional code, I disagree: don't both checking malloc, just rig malloc to blow up when it fails.

You'll do more harm trying to use something like xmalloc and failing to use it consistently (obviously you need to "x" more than just "malloc") than you will by taking steps to guarantee a swift failure to make sure any malloc failure ends the program.

Obviously, in any code where "malloc(3)" is the way you get more memory, I think it's pretty silly to check malloc's return value. You aren't going to get recovery right.

Maybe you're thinking of a different xmalloc than I am? I'm talking about the one from libiberty, which is exactly a way to "rig malloc to blow up when it fails". (edited:) Or do you mean that xmalloc isn't a reliable way to do that because some piece of your code might call malloc instead? Is it better to depend on some nonstandard behavior from the standard library?

I think there are only very rare cases in production code where it makes sense to check malloc's return value and try to recover, but they do occasionally exist.

No, I'm thinking of the exact same thing you're thinking of, and I'm saying the "xmalloc" solution looks like it does the same thing as simply rigging malloc to blow up, but does not do so consistently (because "x" malloc isn't going to be used consistently).

I think we agree about explicit malloc return value checks.

It's good to agree with you about something.

I don't think I understand what you mean by 'obviously you need to "x" more than just "malloc"'. If you use xmalloc() instead of malloc(), and either abjure realloc() or use xrealloc(), haven't you covered all your bases?

It's true that a bug could creep in somewhere, but that hardly seems like a particularly damning criticism. Every place you use xmalloc() instead of malloc() is one less bug, one less potential Mark Dowd Flash exploit. And you can use nm(1) or the Visual Studio equivalent to find out if your program still has any calls to malloc() or realloc(), and then you can remove them.

From my perspective, the problem with rigging malloc() itself to blow up is that there's no portable, standard way to do that. And, if someone fails to do it when they're porting your code to a new platform, everything will appear to work perfectly, but the port will have introduced a subtle bug that may result in remote-root vulnerabilities. That would be really bad.

Try to list all the other functions that need "x" equivalents. Here's a free one: xcalloc.

True! It's already in xmalloc.c, but xstrdup isn't. And if you're using third-party libraries that call malloc(), you're probably screwed unless you have a way to change malloc()'s behavior. So you've basically convinced me.

Yay! Another convert! We're gradually taking over the world.

It is seriously soooo much easier to write C code when you don't have to explicitly check allocation returns. I shaved FOUR THOUSAND LINES out of not- particularly- huge- to- begin- with- server in a previous job simply by getting rid of ridiculous chains of "functions that returned errors that ultimately boiled down to malloc failures", and "call sites to those functions that checked their errors and propagated them". I'll never explicitly check malloc() again.

(There are allocators you do need to check; they just tend not to be called "malloc").

Is there an overview somewhere of the (necessarily nonstandard!) ways of getting malloc() to crash your program instead of returning 0?

So you are saying that adhering to memory bounds and limits (and possibly SLAs) should be ignored in favor of having your software crash because its easier? Sure, I can see it as a possible strategy in some cases. But to go ahead and cite this as a rule is kind of short sighted and a disservice to people who put thought into their memory allocation strategies.

No. I favor not kidding yourself.

Almost no software of any significant size has been written in the last 10 years that can honestly claim to gracefully and reliably handle out-of-memory conditions.

Programming regimes that ostensibly cover out-of-memory cases are usually delusive; they provide for some superficial handling of out-of-memory issues (which usually just devolves to exiting the program anyways), but do nothing to address the myriad instances of malloc calls happening behind their backs in libraries or temporary allocations.

Fuck that. These people are going through extra work which (a) provides no greater user experience and (b) actually harms their program by creating opportunities for missed checks that propagate NULL pointers (which, when offset against, are actually exploitable!) through the rest of their code.

Just have malloc terminate your program for you when it fails and be done with it. You seriously aren't going to get anything else right, and it's silly to waste your time trying anyways.

The exceptions, I think, require that you aren't using tons of buggy third-party libraries. In AAA games and in bare-metal programming, for example, exiting the program is not an option, so you don't use libraries that might do that.

Obviously, in any code where "malloc(3)" is the way you get more memory, I think it's pretty silly to check malloc's return value. You aren't going to get recovery right.

Yikes. And you work in security?

Yes, and my certainty that I am right on this point is clad in iron. You clearly don't understand what I'm saying.

Reply on news.ycombinator.com