What every C Programmer should know about undefined behavior #2/3
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
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.
Posted May 17, 2011 5:36 UTC (Tue)
by gowen (guest, #23914)
[Link] (3 responses)
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
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.
Posted Jun 7, 2011 21:14 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (2 responses)
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.
Posted Jun 8, 2011 13:39 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Jun 16, 2011 0:05 UTC (Thu)
by cmccabe (guest, #60281)
[Link]
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.
What every C Programmer should know about undefined behavior #2/3
> with whether you decide to put declarations at the start.
What every C Programmer should know about undefined behavior #2/3
What every C Programmer should know about undefined behavior #2/3
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