[H-GEN] Re: C programming idioms

[Greg Black]

This topic does not really belong in the General list, as it is of
interest only to developers who have their own list -- however, since
this message appeared here, I'll reply to it here.

On 2007-02-18, Ted Percival wrote:
> bjf at bjf.id.au wrote:
> > My question to the collective consciousness is, what resources do the
> > professional C developers here use as tutorials and references to get
> > this more advanced knowledge that you typically don't find in the "Teach
> > Yourself C for Dummies in 24 Hours" kind of books?
> 
> I've found reading and modifying source to be the best way, particularly
>  that of free software projects.

Unfortunately, this is in fact about the worst way, especially with C,
since most major open source projects have a wide range of code quality
and all boast a huge amount of really bad code.

> On a more technical level it occurred to me that the practice of
> declaring functions static is fairly common but not self-evident in what
> it does.

It's only not self-evident to people who have not yet learned C.  And if
anybody finds it not self-evident, then they do need to spend time with
a good book (e.g., K&R2).

> It makes the function declaration visible only at file scope
> (and within).

This shows a lack of clarity about the issue and possibly a lack of
understanding about the difference between declarations and definitions
in C and it certainly does not completely describe the behaviour of
static functions.

> The benefits are that it does not need an entry point in
> the symbol lookup table and that the compiler can inline it, knowing it
> will not be called by any external code.

This is not strictly true and completely misses the principal reason for
using static functions.

> Of course there's "goto considered harmful". I was initially surprised
> to see how often it is still used, but it can be useful to clean up
> resources allocated within a function, particularly on an error path. My
> experience with this is that it is preferable when the alternative is
> many levels of 'if' branching, with each one only determining whether a
> function call succeeded. In these cases they're really poor men's (C
> coders') exceptions.

In C, the name of the goto that is considered harmful is longjmp() and
you will see it quite rarely.  The target of the C goto statement is
local to a function and the goto statement is regarded as a normal part
of the language.

> With C, it makes a lot of sense to know about how the code will be
> executed once it's compiled. I don't mean for micro-optimisation, but
> knowing how the stack grows, keeping in mind that you're dealing with a
> linear address space and that an array is really just a pointer, and
> that a pointer just points to a bit or memory and you can interpret the
> memory however you like.

An array is not a pointer, it is an array.  The name of an array is a
pointer to the array.  How you can interpret the target of a pointer
depends on a number of factors which are way beyond the scope of a short
message here.

> I've never had much interest in technical books, but you could probably
> find some a helpful reference if you look at publishers of more advanced
> material (eg. O'Reilly publications) rather than the first-timer guides
> (eg. Teach Yourself Foo in 24 Hours). That said, I've never read an
> O'Reilly book so maybe they're not actually any different.

Seriously, I don't think it's wise to recommend books one has not read.
I have read (or at least skimmed) hundreds of O'Reilly books.  While
many of them are useful to a certain extent, I've never seen one that
would be remotely useful to somebody learning C or trying to improve
their C skills.  There are lots of really bad books about C and almost
no good ones.  My recommendations in my previous message on this topic
remain the best I can offer.

If people wish to continue this discussion, might I suggest using the
Developer SIG list (see http://lists.humbug.org.au/mailman/listinfo/dsig
for more information)?  I have set the Reply-To to point there.

Cheers, Greg