mikeash.com pyblog/friday-qa-2012-08-24-things-you-never-wanted-to-know-about-c.html comments

Jeffrey Walton - 2014-07-26 02:15:33

Sat, 26 Jul 2014 02:15:33 GMT

The nested functions are toxic in the case of no blocks. They are mutually exclusive with no-exec stacks (-Wl,-z,noexecstack).

You can't use no-exec stacks because GCC puts a trampoline on the stack.

The loss of no-exec stacks should be a big problem if an organization (or developer) have an SDLC in place.

Gwynne Raskind - 2012-08-30 16:28:26

Thu, 30 Aug 2012 16:28:26 GMT

Peter: Nice catch! Ironically enough, in real code I always use calloc instead of malloc even in cases where I know for a fact it doesn't matter, just to avoid ever writing myself into corners exactly like that one; I only used malloc for this contrived example because I have a habit of falling back to "beginner" habits for example code.

Joke's on me, though; a beginner would almost certainly be using fopen and fread instead of open and read. I just have an aversion to stdio :).

Peter N Lewis - 2012-08-30 12:13:29

Thu, 30 Aug 2012 12:13:29 GMT

Not wanting to nitpick, but shouldn't that be calloc instead of malloc for all exept the first example? Otherwise the returned block for brillig will contain garbage values which will potentially crash in the exception code for free(brillig->gamma).

Interestingly, because of this, despite the verbosity and repetitiveness of the first example, it's the only one that actually safely handles the errors!

rog - 2012-08-30 10:25:22

Thu, 30 Aug 2012 10:25:22 GMT

I quite liked the way that the Plan 9 kernel solved this problem with setjmp/longjmp.

For example, go to this page, search for syspipe and check out how the error handling logic works.
http://plan9.bell-labs.com/sources/plan9/sys/src/9/port/sysfile.c

It's error-prone (you can easily forget a poperror) but it's at least clean and quite easy to check mechanically.

Oh, it also has the problem that local variables aren't guaranteed to stay around after a longjmp, so it's probably only a historical curiosity.

I miss Go's defer statement whenever I program in C these days.

ChadF - 2012-08-27 21:18:38

Mon, 27 Aug 2012 21:18:38 GMT

Exceptions can be used well, but it's tough to do so, and way too much code uses exceptions for expected errors rather than exceptional conditions.

Kinda reminds me of a joke I had with some co-workers a few years back about purposely creating overly complex code in java.

Something with the gist of:



void foo()

{

  // ... some code ...



  throw new EverythingIsFineException();

}



try

{

  foo();



  // ... We reached an error ...

}

catch(EverythingIsFineException ex)

{

}

I think the discussion was something relating to a Rube Goldberg like coding contest.

mikeash - 2012-08-27 20:48:05

Mon, 27 Aug 2012 20:48:05 GMT

Michael Kingsford Gray and Gary Hetzel: Brainlessly dogmatic positions are not welcome here, sorry. Both the idea that C should never be used for anything, and the idea that C is perfectly fine and the only problem is bad programmers, are stupid. If you guys want to hold an argument over which ridiculous position is better, feel free, but please hold it somewhere else.

Gary Hetzel - 2012-08-27 18:44:51

Mon, 27 Aug 2012 18:44:51 GMT

Michael Kingsford Gray: "C" has not ever cost anything to anyone. Buffer overruns are the product either inattentive developers or those who are not as adept at the language as they would like to appear. In the same vein, if you don't know how to use a jackhammer did so anyhow, and created a mess, would you blame the tool?

CUP - 2012-08-27 17:11:21

Mon, 27 Aug 2012 17:11:21 GMT

If you look at the Microsoft autogenerated code, it does something very similar in its TRY - CATCH macros.

In the early 90s I used to use longjmp for the throw and setjmp for the catch point.

Michael Kingsford Gray - 2012-08-27 10:37:18

Mon, 27 Aug 2012 10:37:18 GMT

Anyone who programs in "C" for anything other than trivial applications, should be shot at dawn.
"C" has cost the planet an incalculable amount in just the HUGE cost of undetected buffer over-runs to render using it a crime against humanity.

Gwynne Raskind - 2012-08-24 23:21:03

Fri, 24 Aug 2012 23:21:03 GMT

Justin: Yeah, you were the whole inspiration for all this; I just didn't limit myself to standards-compliance :). (Not the best choice on my part, but GCC and Clang do seem to be fairly ubiquitous these days, in my experience.)

Justin Spahr-Summers - 2012-08-24 18:40:26

Fri, 24 Aug 2012 18:40:26 GMT

Ha, I missed the closing paragraph of the article. :)

Justin Spahr-Summers - 2012-08-24 18:37:25

Fri, 24 Aug 2012 18:37:25 GMT

I did something similar, using only standard C99:
https://github.com/jspahrsummers/libextc/blob/master/include/exception.h

The macros are even more abhorrent, but enable usage like:



try {

    try {

        raise(Exception, NULL);

    }

} catch (Exception, ex) {

    caught = 1;

} finally {

    assert(caught == 1);

    executed_finally = true;

}

Kent Sorensen - 2012-08-24 17:25:08

Fri, 24 Aug 2012 17:25:08 GMT

Interesting article. I'd like to point out AssertMacros.h containing the require_action etc set of macros. To my eyes, you have pretty much ended up with the same solutions to the same problems that those macros solve.

These macros are ancient. I first came across them in the 1992 Develop magazine mentioned in the file header. Unfortunately I don't seem to have that particular issue anymore. I do have a stack of Develop magazines in the basement ...Purely for "historical" reasons, of course...

Grumpy Jameson - 2012-08-24 16:07:33

Fri, 24 Aug 2012 16:07:33 GMT

. In essence, @try in Objective-C and try in C++ are now the same thing, though they're still not interchangeable due to the separation of class heirarchies.

This is only true for Mac 64-bit and iOS. For compatibility, these language constructs still use the old mechanism for 32-bit Mac apps.

Kapil Sachdeva - 2012-08-24 16:03:20

Fri, 24 Aug 2012 16:03:20 GMT

Thanks Gwynne and Mike for the clarifications.

<mike>
Within Cocoa, it's very difficult to use exceptions correctly (they don't cooperate with ARC by default, throwing through framework code is an error, the built-in classes almost always use errors rather than exceptions, etc.) so I don't recommend using them in Cocoa, regardless of their merits in other languages.
</mike>

So this is the actual reason for using NSError vs exception and is because of platform limitations from Apple.

My understanding is that if everything was ideal (from platform support point of view) then the usage of exceptions i.e. try-catch-finally constructs vs error codes/NSError is the way to go to have more cleaner & robust code.

I hope that Apple and bloggers would explain it the way you mentioned i.e "in the context of cocoa" it is recommended to use NSError because of "platform limitations". The discussion on the web makes it sound like try-catch-finally is bad vs error codes in general.

I hope we are on the same page else please do guide.

Regards & thanks
Kapil

mikeash - 2012-08-24 15:47:21

Fri, 24 Aug 2012 15:47:21 GMT

Note that this is another guest article, written by Gwynne, not me.

As for errors versus exceptions, I generally agree with Gwynne here. Exceptions can be used well, but it's tough to do so, and way too much code uses exceptions for expected errors rather than exceptional conditions. Within Cocoa, it's very difficult to use exceptions correctly (they don't cooperate with ARC by default, throwing through framework code is an error, the built-in classes almost always use errors rather than exceptions, etc.) so I don't recommend using them in Cocoa, regardless of their merits in other languages.

Gwynne Raskind - 2012-08-24 15:28:51

Fri, 24 Aug 2012 15:28:51 GMT

Kapil: My stand is the same as Apple's: Do not use exceptions in Objective-C to manage your control flow. The examples I wrote in this article were purely illustrative, not indicative of a way of doing anything.

In the general sense, this whole discussion was completely moot from an Objective-C point of view; the NSError-as-out-parameter paradigm is well-established in modern Cocoa, and it works. This article presents an approach geared towards pure C without clearly advocating any particular methodology at all (which is one of its problems).

Kapil Sachdeva - 2012-08-24 14:56:03

Fri, 24 Aug 2012 14:56:03 GMT

Mike,
I am bit confused by your stance.

<block>
Fortunately, Apple realized how ridiculous this tends to look in Cocoa and deprecated exceptions for error handling, instead opting for the NSError model. The use of exception handling in Objective-C is now reserved (at least in theory) for truly "exceptional" conditions, particularly programmer error.
</block>

I have seen this earlier on web and not necessarily in agreement with Apple on Error vs exception using language constructs like (try,catch, finally) for reasons explained by you in this article i.e. usage of error codes, goto statement, unreadable code etc when not using exception.

What is you stand - should we use exceptions in objective C or not ?

I am not clear as in the same article you are liking Apple's recommendation on NSError instead of exception and you are also exampling how to use try-catch.

Most likely I am missing something here.

Would appreciate if you could guide.

Regards & thanks
Kapil

Iain Delaney - 2012-08-24 14:53:26

Fri, 24 Aug 2012 14:53:26 GMT

Another possibility is what I call the 'Unix Convention'. Your function returns an integer, with zero for success and errors mapped to different negative numbers. Macros for the error codes make things a little easier to read.

When you have a function that returns or creates something, you pass in a pointer to be populated as the last parameter of the function.

Then you can the function, check the return value, and if it's zero, then your pointer is good.

This is how I did some things with a pre-ANSI C compiler. I think it gets you most of the way there.

Kapil Sachdeva - 2012-08-24 14:38:42

Fri, 24 Aug 2012 14:38:42 GMT

There is a nice wrapping of setjmp/longjmp for C that gives you a feel of using Try-Catch as you would do in C++, C# or Java.

http://www.nicemice.net/cexcept/

Goffredo Marocchi - 2012-08-24 14:23:13

Fri, 24 Aug 2012 14:23:13 GMT

Congratulations Mike, I had not see C doing things like that. It sounds almost immoral :P.

Jokes aside, great article as usual :).