I didn't see an bug section in the man. all I saw was all the options and such. And I'd rather not just leave it, I like trying to be neat as possible.
Quote: BUGS
Some buggy versions of gcc complain about the use of %c: warning: '%c' yields only last 2 digits of year in
some locales. Of course programmers are encouraged to use %c, it gives the preferred date and time representa-
tion. One meets all kinds of strange obfuscations to circumvent this gcc problem. A relatively clean one is to
add an intermediate function
size_t my_strftime(char *s, size_t max, const char *fmt, const struct tm *tm) {
return strftime(s, max, fmt, tm);
}
OK nevermind I fixed that... but now.. I get this interesting mess...
o/track.o(.bss+0x0): In function `valid_edge(exit_data *)':
/usr/users/mud/aesdyn/Current/src/track.c:46: multiple definition of `hometown_list'
o/imc.o(.bss+0x131a0):/usr/users/mud/aesdyn/Current/src/imc.c:6819: first defined here
o/track.o(.bss+0x40): In function `bfs_enqueue(room_index_data *, char)':
/usr/users/mud/aesdyn/Current/src/track.c:61: multiple definition of `nation_list'
o/imc.o(.bss+0x131e0):/usr/users/mud/aesdyn/Current/src/imc.c:6823: first defined here
o/update.o(.bss+0x20): In function `neighbor_data type_info function':
/usr/users/mud/aesdyn/Current/src/update.c: multiple definition of `hometown_list'
o/imc.o(.bss+0x131a0):/usr/users/mud/aesdyn/Current/src/imc.c:6819: first defined here
o/update.o(.bss+0x60): In function `neighbor_data type_info function':
/usr/users/mud/aesdyn/Current/src/update.c: multiple definition of `nation_list'
o/imc.o(.bss+0x131e0):/usr/users/mud/aesdyn/Current/src/imc.c:6823: first defined here
collect2: ld returned 1 exit status
this is the end of the list, but... I have no idea what this all means.
You are probably defining those in a .h file, without externing them. If you put, say, int foo; into a .h file and include it in several .c files, you will get that error. The solution is to put extern int foo; in the .h, and int foo; in one and only one C file.
act_info.c:5498: warning: 'lcost' might be used uninitialized in this function
Setting it to zero may get rid of the warning, but doesn't entirely address the problem. Why use a variable in a function if it is always zero? You need to work out why it was not initialized in the first place.
I've noticed that sometimes the compiler will inform you that variables could be used uninitialized even when your code logic guarantees that it will be somehow. Usually pops up the most when you're doing an if check or switch block.
The real test of whether or not the warning is valid is to run the code in Valgrind and see if it reports relying on uninitialized values.
It seems to get confused with things like switches, where you initialize something based on a switch, but also with a default label. That should force the variable to be initialized but the compiler doesn't check it.
It's not too big of a deal, because that warning is supposed to be more of a heuristic, an indication that you might have messed up. The Java 1.5 compilers are better at detecting uninitialized use, but still not perfect (e.g. when switching on enums, even though enums in Java are a special type that, unlike C enums, cannot have values outside the allowed ones).
It doesn't hurt to just initialize the variable to whatever its default value should be.
Running code in Valgrind is no guarantee however that you are not relying on uninitialized code. That only guarantees that in the cases Valgrind saw everything is ok. Valgrind can only check execution paths it saw, after all. The only way to really be sure about it is to do a complete static analysis of the program, looking at all possible ways to enter the function with all possible parameter values etc. Most of the time you can do this in your head, with relatively simple functions at least. Especially when you initialize based on conditionals, it should be easy to determine what the possible conditions are and whether or not the compiler is just confused.
Still, running Valgrind is of course very useful, since most bugs are indeed made in the common case. Still, one should not consider a successful Valgrind execution to be a guarantee that the code is correct because it is possible that there is an edge case that causes the code to crash that Valgrind just didn't happen to see.
Well, yes. That is of course what I meant. Running the suspect code while in Valgrind. It would be a monumental task to know for sure if EVERY possible code path runs smooth and reports no warnings. But then one should probably be testing new stuff in smaller steps. :)