[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  SMAUG
. -> [Folder]  SMAUG coding
. . -> [Subject]  Warnings when trying to compile in C++
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Warnings when trying to compile in C++
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1  2 

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Fri 15 Dec 2006 02:37 PM (UTC)  [ quote  ]
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. :)
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Thu 14 Dec 2006 09:04 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Samson   USA  (683 posts)  [Biography] bio
Date Thu 14 Dec 2006 03:16 PM (UTC)  [ quote  ]
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.
SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Wed 13 Dec 2006 09:17 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 07:38 PM (UTC)  [ quote  ]
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
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Wed 13 Dec 2006 06:24 PM (UTC)  [ quote  ]
Message 
CHAR_DATA * ch = NULL;
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 05:49 PM (UTC)  [ quote  ]
Message
How do you initalize something like... CHAR_DATA *ch though?
Everything turns around in the end
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Wed 13 Dec 2006 09:20 AM (UTC)  [ quote  ]
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
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 07:59 AM (UTC)  [ quote  ]
Message
Not... exactly the same problem but I still dont know what exactly this means... or how to fix it.

act_info.c:5498: warning: 'lcost' might be used uninitialized in this function

Everything turns around in the end
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 02:35 AM (UTC)  [ quote  ]
Message
Uh, nevermind... I got it... thanks!
Everything turns around in the end
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 02:33 AM (UTC)  [ quote  ]
Message
Well that cut the list down to like... half...
Everything turns around in the end
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Wed 13 Dec 2006 01:35 AM (UTC)  [ quote  ]
Message
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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 12:57 AM (UTC)  [ quote  ]
Message
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.
Everything turns around in the end
[Go to top] top
Posted by Metsuro   USA  (389 posts)  [Biography] bio
Date Wed 13 Dec 2006 12:34 AM (UTC)  [ quote  ]
Message
Well I got around that problem it seems that my_strftime was already put in... but was never really ever used... but now I have this further on.

hometowns.c:326: initialization to `char *' from `const char *' discards qualifiers
I had a few more of these and I added const and it fixed it.
Everything turns around in the end
[Go to top] top
Posted by Zeno   USA  (2,867 posts)  [Biography] bio   Moderator
Date Wed 13 Dec 2006 12:13 AM (UTC)  [ quote  ]
Message
A little odd. Here's what I have:
char * current_date( ) 
{ 
    static char buf [ 128 ];
    struct tm * datetime;

    datetime = localtime( &current_time );
    strftime( buf, sizeof( buf ), "%x", datetime );
    return buf;
}


Yet I don't get a compile warning.


Here's the bug section from the man page:
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);
}
Zeno McDohl,
Owner of Bleached InuYasha Galaxy
http://www.biyg.org
[Go to top] 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.

6,171 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]