Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ SMAUG
➜ SMAUG coding
➜ Warnings when trying to compile in C++
|
Warnings when trying to compile in C++
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #15 on Wed 13 Dec 2006 09:20 AM (UTC) |
| Message
| | It means that you didn't initialize the variable. Set it equal to 0 or whatever it should be. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Metsuro
USA (389 posts) Bio
|
| Date
| Reply #16 on Wed 13 Dec 2006 05:49 PM (UTC) |
| Message
| | How do you initalize something like... CHAR_DATA *ch though? |
Everything turns around in the end | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #17 on Wed 13 Dec 2006 06:24 PM (UTC) |
| Message
| |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Metsuro
USA (389 posts) Bio
|
| Date
| Reply #18 on Wed 13 Dec 2006 07:38 PM (UTC) |
| Message
| | At this rate Ksilyan I am just gonna have to get a direct line to you :P thanks for the help. I'll prolly be back with some more questions later! |
Everything turns around in the end | | Top |
|
| Posted by
| Nick Gammon
Australia (23,169 posts) Bio
Forum Administrator |
| Date
| Reply #19 on Wed 13 Dec 2006 09:17 PM (UTC) |
| Message
|
Quote:
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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #20 on Thu 14 Dec 2006 03:16 PM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #21 on Thu 14 Dec 2006 09:04 PM (UTC) |
| Message
| 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. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #22 on Fri 15 Dec 2006 02:37 PM (UTC) |
| Message
| | 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. :) | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
72,091 views.
This is page 2, subject is 2 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top