An even better reason to use clang: it supports Apple's new syntax for blocks. I'm trying to think of a new project to write in C now just to take advantage of the simple anonymous functions and closures that are possible.
Proprietary extensions are one reason that gcc is so hard to unseat. You're always better off writing standard code if you want it to work in ten years.
Hardly proprietary. Apple gave the "block" patches to the gcc team. Gcc isn't interested in them, they are holding off for some future C++ syntax, though I don't see how that helps C programmers.
Meanwhile, I got seduced by gcc's nested functions which are not supported by clang. Apparently they are non-trivial in clang so won't appear soon if at all.
Two incompatible mechanisms for function decomposition are annoying.
("blocks" does a lot more, but for the afflicted project I don't need that. Just nested functions would be spiffy, it saves the plethora of arguments being passed to each function if you keep them at file scope.)
"Gcc isn't interested in them, they are holding off for some future C++ syntax, though I don't see how that helps C programmers."
You are assuming that C programmers need to be helped.
The beauty of C lies in its simplicity, not in its features. That's what has kept C alive to this day despite its shortcomings, and despite the existence of C++.
C does not need new constructs. C needs to be kept as simple and as close as possible to the hardware, it needs to continue to be a high-level assembly. That's what C is mostly used for.
If you feel C needs more features, you are probably using the wrong language for the job.
Closures in C make me uncomfortable, but lexically scope subfunctions are just syntax that serve two functions for me.
First: organization. If I grab a chunk of function and put it in nicely named subfunction, even if it is only called once it lets me keep each function to a nice size. This could be done with a static function, but then you always have to think: "What else in this file might call this function?"
Second: (And much more empowering) Gathering together repetitious code can be cleaner. Consider implementing some network protocol. You will probably have a "get next byte from buffer" function which will need access to the buffer, the current position, the number of valid bytes in the buffer, and who knows what else. You could make this a static function and pass all the arguments in, correctly, each time and if you only need a single value back that works. With a lexically scoped subfunction you can just reference these in the outer scope and if you need to set an error condition or message just set it in the outer. Very clean. No scary runtime code.
Yes, nonstandard. I apologize for my sloppy wording.
By all means play with closures. I don't mean to discourage the original poster from experimenting. I am just pointing out some irony in the context of gcc and clang. Clang is forced to implement nonstandard gcc extensions. I do not see this as a good thing for languages that are essential building blocks and which people have put a lot of work into standardizing. Software development doesn't need to be so ephemeral.