Hacker News Reader

Comment by meaty | Hacker News Reader

I was excited until I saw "use autotools".

edit just bought it.

Quick scan reveals some GNU extensions being used, lots of tripe about pkg-config, autotools, how to write a makefile properly without autoconf (commendable), gdb tutorial (looks resonable), short valgrind mention, unit testing, doxygen, proper assertions (woot!), short bit on VCS with git (looks reasonable), integration with python (looks reasonable), decent discussion on aliasing and copying, some serious standard-breaking things (bad), how not too shoot yourself with macros (good), linking discussion (looks ok), an odd quote from pussy riot, lots of discussion of gotchas, unicode (good!), some stuff to do with glib (yuck), OOP in C (looks ok), more glib stuff (yuck), posix threading (some mines in there), GSL (good), SQLite (good), libxml (yuck - personal preference though), libcurl (good).

So generally a mix of good and bad. Probably worth it though.

View on HN

Thanks for posting this. I often wondered `what are the Y-combinator people are going to say about this...?' while writing some opinionated section of the book, and the reaction seems pretty positive so far. Nobody has yet compared it to K&R...

There _is_ a lot of GNU in there, but that's because there's a lot of GNU in the C ecosystem. I made an effort to neither overuse or underuse GNU tools, and this is where I wound up. Also, I made a serious effort to label anything that's GNU-specific as such, e.g., the long segment on the GNU/BSD-specific asprintf() (which I was _so_ disappointed to not see adopted in C11).

Everything tests out on clang unless otherwise stated. In fact, there are little things that work better on clang, because it uses c99 out of the box. E.g., as of this writing, you'll need clang to make the example for (C11) _Generic work. If anything breaks standards without my telling you it does, you can file a bug report at O'Reilly's site for the book (or email me), and I'll fix it in later electronic versions.

As for autotools, I had a sort of epiphany somewhere along the course of writing the book: it's not so bad. At the core, if you want to do something relatively simple, like set up a basic shared library, you can do so in just a few lines of Automake. It's filled with hacks and historical cruft, but as a user I...I've grown to actually like it. Also, as above, it's a huge part of the ecosystem and therefore worthy of discussion for that reason alone. If you don't like it, skip the Autotools chapter and stick with make. I won't know.

You also acknowledge, in the text, that autotools gets some hate, and you justify its use and your inclusion of it in the book.

My sense of the book so far-- though I've only had it for a day or two-- is that it's pretty balanced in terms of avoiding evangelical fervor for any one tool or approach.

thanks for the reply - its nice to get an insight on your perspective. My commentary above doesn't detract from my opinion which is basically: looks good, definitely didn't waste my cash. Inevitably there is stuff people disagree with - there isn't a worthy book out there that doesn't fit that description.

We've needed a book like this for a while :)

I look forward to future editions as well.

> I was excited until I saw "use autotools".

People love to gripe about autotools, but if you take the time to understand it and get comfortable with what it is and is not, it will get the job done.

There are alternatives like cmake, but they just suck differently. I use autotools to manage cross-platform (Linux/glibc, Linux/uclibc, mingw32, OS X) C library projects and their Python extension module wrappers, with heavy dependencies on system-specific functionality and symbol replacement (e.g., if strlcpy isn't in libc, then link in libbsd if you can find it there, otherwise compile our own copy of strlcpy.c). Autoconf is a wonderful tool for this once one RTFMs and gets over the fact that it's a bunch of helpers for writing a shell script, rather than a fully abstracted programming language of its own.

Or in the words of Lennart Poettering, "every custom config/makefile/build system is worse for everybody than autotools is":

https://git.kernel.org/?p=linux/kernel/git/kay/libabc.git;a=...

I wonder why the author decided integrating with python was a better idea than, say, lua. Seems to me that lua is winning that fight, but that's just my current impression - I don't really have any solid numbers to back that up.

Lua also makes it very, very easy to integrate it with a C program.

Which fight? As an embedded language, Lua is more popular, yes. Outside of this, probably not.

That's what I was saying - if you wish to talk about integrating a scripting language with C in the 21st century, odds are it will be lua, not python.

Tell that to the scipy folks.

Well in this case, it's more integrating Python with C i.e. writing a C callable and calling it from Python.

I'm not really a Lua fan personally (the confusing indice and ordinal notation scares me), but I can see why it makes sense for integration purposes. Clean, simple, to the point.

Having just completed a large project with Lua, I have to say that the indice/ordinal notation thing is something that we quickly got used to. In fact, some nice succinct idioms work because elements run from 1 to arraySize (inclusive).

Seems like something where you want to illustrate the concepts of integrating with a scripting language:

* Calling out from your C program to the scripting language.

* Setting variables in the scripting language from C.

* Creating functions that can be called from the scripting language.

* Making those available by creating a loadable shared lib that the scripting language can utilize.

Stuff like that is not that different across different languages and if you've figured one out, others won't be that hard.

My take: Tcl's C API is pretty cool. I wrote about it some here: http://www.amazon.com/dp/032133633X/?tag=dedasys-20

Python usage is much more.

How mature is string manipulation in Lua? Personally, I use python for anything involving string manipulation, and then use C or C++ (depending on context) to do significant data processing on the (now hashed) data.

Lua's core string manipulation has been kept (as I understand it) deliberately limited in order to keep the implementation simple. What is present - e.g., simplified pattern-matching - is cleverly designed and often useful but, by design, there's nothing to compare to Python's rich built-in set of libraries.

>some serious standard-breaking things (bad)

Could you expand on this perhaps? The book sounded pretty compelling up until I read that.

Mainly GCC specific features. No C99 there.

The book should have the word "GNU" wedged in it.

I'd like to have seen some discussion of llvm/clang as well.

clang and gcc are not very different from a user's point of view—clang deliberately supports a large number of gcc extensions and command-line options. For that matter, so do other C compilers (e.g. the EDG front-end, used by the intel C compiler).

So really these days "gcc" is as much a common dialect of C as it is a particular compiler.

Any comments on the amount of factual errors as mentioned in the 3-star amazon review?

I haven't actually read it properly yet :)

That's a really good and evenhanded review. Thanks for spotting it.

Just curious, what's wrong with glib? I happen to like it a lot, and it's a good option for getting access to data structures that other languages take for granted.

Some horrible design and so many typedefs (gpointer being the largest yuck if you ask me). Who needs to typedef void* ?

Also it leads to GObject abuse which is harmful to the soul.

Ultimately, the moment you bring glib into a project it stops being C, much like the Win32 API does.

I'd rather pull in libapr and apr-util.

gobject is built on top of glib, not the other way around, and it's mostly there to make it easier to create language bindings, so there's no real reason to use it (gobject) unless you're building a library like GTK. As for the typedefs, they're there for consistency more than anything. A couple of them are legitimately useful for portability reasons, but the rest (like gpointer) are there simply to keep things looking similar in the API.

Say what you will, but I see the book's apparent inclusion of glib as a plus.

I'll second that, I guess I'm biased as I wrote some early gnome stuff back in the day before I started writing graphics device drivers for Precision Insight and VA Linux systems. I rather like glib, even though the gpointer thing isn't something I like too much aesthetically. Everything obviously has its warts and trade offs, nothing is perfect after all. I think glib brings a lot to the table though and with it and a few other choice libraries I can code very complex projects just as fast or faster in C as I do in Java.

Would you care to list your other "choice libraries" ? I'm not familiar with actually programming in C (I can read C somewhat, but have never used it for a real (even small) project).

The complaint about typedefs and Win32 is kind of odd. These are style choices that libraries and large projects should be entitled to make.

I used to work at MS and grew very comfortable (and appreciative) of the stylistic choices in the NT kernel (distinct from the Win32 style, one key difference is much less Hungarian notation). But I can jump back into more typical-of-*nix styles with ease. Or the more Win32 style if preferred. I think it's important to see the merits and drawbacks of various style decisions in a non-judgmental fashion, and be able to switch back and forth depending on the code base you're working in. It's a mistake to confuse style and convention with "not being real C". Different doesn't mean not real.

>I'd rather pull in libapr and apr-util.

I haven't checked recently, but the problem with APR was for so many years it had (possibly still has) no documentation other than Doxygen. Also, the memory pool design seemed an enormous complication. Have you used it recently and have either of those factors improved much?

Could you elaborate on the 'horrible design'? In general, I've found GLib very useful (say, the data structures, mainloops, GError, the G_GNUC_ stuff, ...) . If the biggest problem is some typedef that you can happily ignore, it can't be that bad, or?

GObject is a bit different matter - there's quite a bit of boilerplate, which makes me think twice before adding one. But at the same time, it's quite nice to use them in libraries like GStreamer.

GLib is certainly not perfect, but I found it more pleasant to use than, say, talloc. Are there any specific advantage is APR? (I've never used it) Does it cover the same functionality?

So basically this is a Modern C for Linux book.

Is there an alternative that actually works?

Yeah: make and knowing what you are doing.

I've built some seriously complicated stuff which builds on Linux, Solaris and FreeBSD in the past with no autoconf magic required.

Autoconf is just a massive Rube Goldberg machine in disguise.

It arose out of a different time. Linux/Solaris/BSD are trivial, compared to all the differences of the commercial unices of ages past, with their idiosyncratic libraries, BSD vs. SysV vs. POSIX, never mind all the different compilers. People would've sacrificed their firstborn to get something running on both HP/UX and SunOS, compared to that autotools was a blessing.

I think there are more papers on build systems than on sort algorithms.

I've been through that as well. I have in the past just provided a different Makefile for each platform and run as follows:

    make -f Makefile.osf1
    make -f Makefile.sunos4
    make -f Makefile.sunos5

There is usually little difference between them - mainly compiler names/flags and the occasional def for code. Occasionally make is broken at which point you have to frig something.

Keep It Simple is the #1 rule. Rule #2 is every bad thing you do will do two things bad back to you in the future.

Agree with meaty: make and knowing what you're doing is good.

Occasionally, though, my needs will be more complicated than what make can handle on its own (lots of compile-time options, for example, or lots of dependency checking), and in those cases I'll use waf. Waf is lovely and hasn't let me down, and it's easy to use for people who are used to the ./configure && make && sudo make install sequence.

Redis uses many advanced POSIX features and some OS-dependent API (see ae.c) without autoconf, but just some minor ifdeffing business.

+1. When I read your code, I know there is hope yet :)

You are too kind! Thanks.

It depends on what you mean by works. CMake actually works for me.

I've never liked CMake, but equally I've never really been able to articulate why that is.

We decided to use gyp instead of autoconf and with some tweaking shipped a massive library that builds on Linux, Solaris, FreeBSD, OSX, AIX, HP-UX, Windows w/ it in both 32/64-bit. Definitely not for the feint of heart, but it is possible.

Check out http://swtch.com/plan9port/, it's a huge project that runs on (to quote the site) Linux (x86, x86-64, PowerPC, and ARM), FreeBSD (x86, x86-64), Mac OS X (x86 and Power PC), NetBSD (x86 and PowerPC), OpenBSD (x86 and PowerPC), SunOS (Sparc).

It uses a shell script to do a little bit of config, then bootstraps mk (a Bell Labs successor to make) and builds everything from some very human-readable mkfiles. When you want to build, you just untar the source and run ./INSTALL

Ta, will take a look.

What do you recommend over libxml? And by libxml did you really mean libxml2? I prefer to work with a DOM parser and I don't know of anything better.

I recommend avoiding XML. Its the most nuanced markup/data representation language there is.

Reply on news.ycombinator.com