What every C Programmer should know about undefined behavior #2/3 [LWN.net]

What every C Programmer should know about undefined behavior #2/3

Posted May 16, 2011 21:35 UTC (Mon) by cmccabe (guest, #60281)
In reply to: What every C Programmer should know about undefined behavior #2/3 by gowen
Parent article: What every C Programmer should know about undefined behavior #2/3

Ok, I know I'm replying to a blatant troll, but let me just point out that:

1. Initializing something before checking if it's NULL has nothing to do with whether you decide to put declarations at the start.

2. C99 doesn't have a "declarations go at the start of the block rule."

That being said, a lot of people consider it good style in C to put the declarations at the start of the block in C, because it encourages you to keep functions short and sweet.

to post comments

What every C Programmer should know about undefined behavior #2/3

Posted May 17, 2011 5:36 UTC (Tue) by gowen (guest, #23914) [Link] (3 responses)

> Ok, I know I'm replying to a blatant troll

I don't think that word means what you think it means. Clue: It doesn't mean "someone who doesn't share my opinion".

> 1. Initializing something before checking if it's NULL has nothing to do
> with whether you decide to put declarations at the start.

Combined with a coding rule that variables must be initialised when declared, it really kind of does. And thats a common coding rule, because using an unitialised variable is - surprise - undefined behaviour. The vertical space between a variables declaration and its initialisation represent a region in which using that variable is a bug. It is good practice to keep that space as small as possible ("but no smaller" being the extra advice thats forgotten in this case). Yes, its not an unavoidable bug. But its an unnecessary vector for bug transmission.

So, as mentioned above this clash of good advice - or rather, a slightly blind application of usually-good advice - combined with C89's archaism on variable declaration resulted in a bug.

For the recent Linux hole, why do *you* think the (presumably experienced) coder initialised the variable on declaration - which sadly preceded the NULL check?

> 2. C99 doesn't have a "declarations go at the start of the block rule."

I did actually mention that. So zero out of ten for reading the whole post.

What every C Programmer should know about undefined behavior #2/3

Posted Jun 7, 2011 21:14 UTC (Tue) by cmccabe (guest, #60281) [Link] (2 responses)

The reality is that code written in C, C++, and other unsafe languages will always have "holes." We can minimize the holes by careful sandboxing and code inspection, but never quite get them to zero.

Cherry-picking one example of a hole and then using it to justify your style preferences is fairly silly. I could equally well find an overflow caused by signed overflow and say "aha! signed numbers are teh evil."

The reason why I prefer the C89 style of initializing the variables at the top of the block is that it tends to lead to shorter, clearer functions. If you end up with a page worth of declarations, it makes it clear even to the dullest programmer that his function is getting too long. It also makes it clearer how much stack space is actually being used, which is nice when you're really going for performance. And if you're not going for performance, what are you doing using C?

I understand the arguments for the C99/C++ "declare right before use" style. In C++ it's almost a must, because declarations trigger constructors to run, consuming CPU cycles. It also works well with C++'s RAII style. It also can move the definition closer to the use, making it easier to see the type. But again, that assumes you are writing gigantic, multi-page functions, which you *should not do*.

So basically, I think we are going to have to agree to disagree, for C at least. For C++, yes, you should declare as close as possible to where you use a variable.

What every C Programmer should know about undefined behavior #2/3

Posted Jun 8, 2011 13:39 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

If you end up with a page worth of declarations, it makes it clear even to the dullest programmer that his function is getting too long.

You have too much confidence in dull programmers. I have worked on functions with ten pages of variable declarations at the top. (The functions themselves were ten thousand lines long, which *anyone* should have realized was too long, but they had grown slowly to that length and nobody wanted to take the 'risk' of splitting them.)

What every C Programmer should know about undefined behavior #2/3

Posted Jun 16, 2011 0:05 UTC (Thu) by cmccabe (guest, #60281) [Link]

Heh, that sounds like a story from thedailywtf.com

Anyway, lazy or careless people can always find a way to do lazy or careless things. It is nice if you get a helpful hint that what you are doing is wrong, though. For example, using 4 or 8 space indents tends to give you a wakeup call that 20 levels of nesting might be more than the human mind can understand in C or C++. Using 1 or 2 space tabs does not. etc.