GCC Warning: variable might be used uninitialized
Hi, Should we always initialize our int (perhaps this applies to char as well) to something so we dont risk using it uninitialized (well at least that is what gcc warns while using to the -Wall flag) ??? ( Even though knowing our code on a normal situation it is imposible that it happens) Example: int i; int z; for(i=0;i<10;i++) { if(i==5) /* we are definitely coming in here so I have no need to give z a value*/ { z=i; printf("%d\n", z); } }
Should we always initialize our int (perhaps this applies to char as well) to something so we dont risk using it uninitialized (well at least that is what gcc warns while using to the -Wall flag) ??? ( Even though knowing our code on a normal situation it is imposible that it happens)
Basically, yes, because initialising variables is a very good habit to get into. In the example you gave it doesn't make any difference, but if you change the code at some point such that i is used before the loop, you might forget it needs initialising and make yourself a tricky to find bug. As for z, I'd do this: int i=0; for(i=0;i<10;i++) { if(i==5) { int z=i; printf("%d\n", z); } } It's always a good idea to declare a variable as close as possible to the place it's used. Readers of your code then won't need to go paging up so far to find the variable type or initialisation. -- "...our desktop is falling behind stability-wise and feature wise to KDE ...when I went to Mexico in December to the facility where we launched gnome, they had all switched to KDE3." - Miguel de Icaza, March 2003
On Tue, 2003-04-15 at 04:46, Derek Fountain wrote:
if(i==5) { int z=i; printf("%d\n", z); } }
It's always a good idea to declare a variable as close as possible to the place it's used.
Beware though that this was banned in C89, so a strictly conforming compiler would barf on it. I think it's legal again in C99.
Readers of your code then won't need to go paging up so far to find the variable type or initialisation.
Two comments, first you shouldn't have procedures so long that you have to go paging up to find the start of it. And second, to my mind it's much better to have all declarations in one place. If, 50 lines later you see variable z used, where will you look for its declaration?
if(i==5) { int z=i; printf("%d\n", z); } }
It's always a good idea to declare a variable as close as possible to the place it's used.
Beware though that this was banned in C89, so a strictly conforming compiler would barf on it.
I'm referring to placing the declaration of a variable just inside the block where it is used. i.e. inside the opening brace, as in the example above. That was never illegal - was it? I assume that you're referring to the C++ practise of putting a declaration absolutely anywhere?
Two comments, first you shouldn't have procedures so long that you have to go paging up to find the start of it.
How long do you suggest, then? :o) Seriously, it's been shown that the length of a piece of code does little to affect the readability of it. What affects the readability is the complexity: the number of conditions, loops, variables, etc. A 100 line, drop-through routine which implements e.g. a state machine, is very simple to read. Breaking up a simple piece of code purely on the basis that it's "too long" makes little sense.
And second, to my mind it's much better to have all declarations in one place. If, 50 lines later you see variable z used, where will you look for its declaration?
Hmmm. You're contradicting your first argument! :oP But since I've done that myself, I should answer the point. This is the "principle of proximity" which CS lecturers often refer to: keep related actions together. Keep variable declarations near to where the variables are used; keep comments near the code it refers to, etc. Your point is valid, but it's an unusual scenario. Much more likely is that a variable is not used throught an entire function; use of a variable is much more often isolated to a specific job in a specific part of the code. Putting all variable declarations in one place gives the impression that all the variables are used throughout the whole routine. Another point is that if a variable is declared a long way from where it is used, yes, as you say, you have to go and find it when you need to see its declaration, but also you have a lot of code to search though when you're trying to find where it's been changed. That makes finding bugs harder when you discover the variable isn't containing the value you expect. This problem is especially so someone has been back to modify a piece to older code. -- "...our desktop is falling behind stability-wise and feature wise to KDE ...when I went to Mexico in December to the facility where we launched gnome, they had all switched to KDE3." - Miguel de Icaza, March 2003
On Tue, 2003-04-15 at 05:48, Derek Fountain wrote:
I'm referring to placing the declaration of a variable just inside the block where it is used. i.e. inside the opening brace, as in the example above. That was never illegal - was it?
No, not as the first line of a block, that's always been legal (I think). I missed that.
I assume that you're referring to the C++ practise of putting a declaration absolutely anywhere?
That is what I was thinking of, yes, but it's not just in c++. In K&R C it was allowed to have things like for (int i = 0; i < 5; i++){ fprintf(stderr, "foo\n"); int a = 3; } and, apparently, that's legal again in C99.
Two comments, first you shouldn't have procedures so long that you have to go paging up to find the start of it.
How long do you suggest, then? :o) Seriously, it's been shown that the length of a piece of code does little to affect the readability of it.
I disagree. I remember from comp.sci. class studies on this type of thing, but I mainly go on personal experience. When I have to make sense of a large program, I find it much simpler if it's subdivided into logically distinct parts (procedures or methods) with well defined purposes. How long? Some people say one screen, but I don't much like reading a lot of code on screen. I prefer no more than one page of paper when it's printed out. If it's much longer, except in extreme circumstances, it's very likely to be poorly written anyway.
What affects the readability is the complexity: the number of conditions, loops, variables, etc. A 100 line, drop-through routine which implements e.g. a state machine, is very simple to read. Breaking up a simple piece of code purely on the basis that it's "too long" makes little sense.
I agree that to some extent it depends on the code.
And second, to my mind it's much better to have all declarations in one place. If, 50 lines later you see variable z used, where will you look for its declaration?
Hmmm. You're contradicting your first argument! :oP But since I've done that myself, I should answer the point.
This is the "principle of proximity" which CS lecturers often refer to: keep related actions together. Keep variable declarations near to where the variables are used; keep comments near the code it refers to, etc.
Absolutely, but I feel this is the role of the procedure. With the short procedures I talked about, the first line(s) of the procedure is, I believe, the right place to have variable declarations.
Another point is that if a variable is declared a long way from where it is used, yes, as you say, you have to go and find it when you need to see its declaration, but also you have a lot of code to search though when you're trying to find where it's been changed. That makes finding bugs harder when you discover the variable isn't containing the value you expect. This problem is especially so someone has been back to modify a piece to older code.
True
On 15 Apr 2003 06:25:32 +0200 Anders Johansson <andjoh@rydsbo.net> wrote:
That is what I was thinking of, yes, but it's not just in c++. In K&R C it was allowed to have things like
for (int i = 0; i < 5; i++){ fprintf(stderr, "foo\n"); int a = 3; } I don't think this was every legal in K&R and I know it is not in C89. For one, K&R never allowed the initialization of automatic variables, but as I mentioned, some compilers did. As you mention, the above code is legal in C++. I'm not sure about C99. (BTW: Reading my copy of K&R 1978 in a block, the declaration list followed by the statement list. Also, variables in a block may be initialized (I think that I may have mentioned that it was illegal in K&R. In K&R, aggregate initialization of automatic variables was illegal).
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Tue, 2003-04-15 at 15:04, Jerry Feldman wrote:
On 15 Apr 2003 06:25:32 +0200 Anders Johansson <andjoh@rydsbo.net> wrote:
That is what I was thinking of, yes, but it's not just in c++. In K&R C it was allowed to have things like
for (int i = 0; i < 5; i++){ fprintf(stderr, "foo\n"); int a = 3; } I don't think this was every legal in K&R and I know it is not in C89. For one, K&R never allowed the initialization of automatic variables,
I'm sure you don't actually mean that K&R actually banned giving values to automatic variables, but if you mean "initialization at time of declaration", I can't really argue the subject with any authority since the only book still in my bookshelf is the second edition, so I can't give any quotes about K&R C. All I can say is that I've seen it in compilable code (a long time ago).
but as I mentioned, some compilers did. As you mention, the above code is legal in C++. I'm not sure about C99.
Neither am I, I haven't actually seen the C99 standard, but gcc complains if set to -std=c89 but not if set to -std=c99. Hence "apparently" in my previous mail.
On 15 Apr 2003 20:19:55 +0200 Anders Johansson <andjoh@rydsbo.net> wrote:
For one, K&R never allowed the initialization of automatic variables,
I'm sure you don't actually mean that K&R actually banned giving values to automatic variables, but if you mean "initialization at time of declaration", I can't really argue the subject with any authority since the only book still in my bookshelf is the second edition, so I can't give any quotes about K&R C. All I can say is that I've seen it in compilable code (a long time ago). Actually, I checked and corrected myself. K&R allowed the initialization of automatic variables: { int i = 10; But not aggregates, like arrays. That was one of the things the standard (C89) changed. Before C89, there were many differences between compilers and dialects of C. The C89 standard changed all that.
I have a draft copy of C99, but I have not had a need to get the actual standard. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
Beware though that this was banned in C89, so a strictly conforming compiler would barf on it. I'm pretty sure you are incorrect in this (I briefly checked my copy of
On 15 Apr 2003 05:05:37 +0200 Anders Johansson <andjoh@rydsbo.net> wrote: the standard). It is perfectly legal in C89 to define a variable within a block, whether that block in the block. In K&R (traditional) the initializing of an automatic variable was generally illegal (depending on the compiler). C89 explicitly made this legal: if (condition) { int i = 0; }; However, I don't always initialize automatic variables. if (condition) { int i = 0; for(i=0; i < 10;i++) { } }; In this case, the initialization of i is redundant. But, it is also a common mistake for programmers to fail to initialize automatic variables before they are used, which can have many consequences. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Tue, 2003-04-15 at 14:49, Jerry Feldman wrote:
I'm pretty sure you are incorrect in this (I briefly checked my copy of the standard). It is perfectly legal in C89 to define a variable within a block, whether that block in the block.
Yes, I already mentioned in my reply to Derek that I missed that the declaration was the first line of a block. It war 4 in the morning, I'm sorry :)
On 15 Apr 2003 20:21:50 +0200 Anders Johansson <andjoh@rydsbo.net> wrote:
Yes, I already mentioned in my reply to Derek that I missed that the declaration was the first line of a block. It war 4 in the morning, I'm sorry :) Don't code without sleep :-)
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
participants (4)
-
Anders Johansson -
Derek Fountain -
Jerry Feldman -
Raúl Gutiérrez Segalés