[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]  New Linux, New GCC, New Warnings
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: New Linux, New GCC, New Warnings
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  3  

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Wed 16 Jan 2008 08:11 AM (UTC)  [ quote  ]
Message
SMAUG (and similar) code is notorious for having, err, somewhat sketchy code constructs. Some of these have already started cropping up as common errors, such as the 'invalid lvalue cast' one that comes up from time to time. SMAUG also uses const very poorly, and in fact generally doesn't use it at all. This makes life very complicated when you want to start doing things properly with 'const' in functions like one_argument, because it makes every calling location report an error unless it was using const (and most of them don't) -- but then fixing those just causes the error (or warning) to propagate backwards further.

I still think that forcing people to program correctly is a good thing, because many bugs are caused by things like this -- mishandling of strings, for instance, that wouldn't have happened had they been properly const'ed. But Samson is right in that this will cause all kinds of trouble for fixing it. It's a case where the small cost way back when to do things the right way would have prevented the very large cost most people are going to be faced with now if they upgrade gcc versions.

</soapbox> :-)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Robert Powell   Australia  (349 posts)  [Biography] bio
Date Wed 16 Jan 2008 07:55 AM (UTC)  [ quote  ]
Message
Quote:

For MUD code, I suspect there's going to be some major headaches on the horizon since Smaug, Rom, Godwars, Merc, Circle, and most of the others will run into the same kind of roadblocks that drove me to using std::string.


Do you mind elaborating further? what sort of issues should i be aware of, what future troubles possibly lie in wait within smaug code?
EldhaMUD Game Developments
The_Fury: Lead Developer, Head Coder
http://fury.eldhamud2.org
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Wed 16 Jan 2008 05:01 AM (UTC)  [ quote  ]
Message
I think that the past always catches up to people with heaps of interference; I think that's almost the definition of the past catching up to you. ;-)
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 Wed 16 Jan 2008 04:44 AM (UTC)  [ quote  ]
Message
I understand the reason for making the change, but in this case the inconvenience was non-trivial for a whole lot of people. Not just us sloppy MUD coders this time :)

I turned up Google hits from all sorts of angry project leaders, up to and including folks working on the Gnome and KDE projects. It may be proper behavior but it's likely slowing the adoption of 4.2.x more than normal as all these people need to stop and fix stuff rather than getting real productive work done.

For MUD code, I suspect there's going to be some major headaches on the horizon since Smaug, Rom, Godwars, Merc, Circle, and most of the others will run into the same kind of roadblocks that drove me to using std::string. It may well be inevitable that the past catches up to us, but it would have been nice for it to catch up with less interference.
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 Tue 15 Jan 2008 07:28 PM (UTC)  [ quote  ]
Message
Quote:
because the whole thing was just being ridiculous about the const flag.

Well, it's actually doing you a big favor, from a certain point of view... If you recall that social bug from the FUSS forums, that was almost solely due to not understanding and therefore mishandling const strings. In the end of the day the compiler is just strongly encouraging people to actually program properly and not be lazy or ignorant about const. Sure, it causes some grief, but how much grief has been caused by screwing up on subjects that the compiler now warns you about?

Quote:
in mud.h is what was changing it, can
char * str_alloc args( ( const char *str ) );

i did this and now
note->sender = STRALLOC( sender );

compiles without warnings, but is it correct what i did, or could this actually induce more problems for me than just correcting 1 warning on a cast.

This is fine; it was seeing the declaration in mud.h, not the prototype in hashstr.c. So, it only knew about the non-const version.
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 Tue 15 Jan 2008 02:25 PM (UTC)  [ quote  ]
Message
Ah, so they're finally starting to slip 4.2 into more common distros eh? Lovely. I've been looking to avoid it myself since a lot of these kinds of warnings are going to cause grief on an epic scale. Code that "worked fine" before suddenly "breaks" and has to be "fixed". It's gcc3 syndrome all over again :)

I forced the const errors to the surface in AFKMud by using the write-strings compiler flag and ended up giving up and going with std::string because the whole thing was just being ridiculous about the const flag.
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 Robert Powell   Australia  (349 posts)  [Biography] bio
Date Tue 15 Jan 2008 09:34 AM (UTC)  [ quote  ]

Amended on Tue 15 Jan 2008 09:40 AM (UTC) by Robert Powell

Message
Ok, i did not have that mismatch like you did nick, both the prototype and the function were both char * str.

I made both const char *, changed this

note->sender = STRALLOC( ( char * )sender );

to this

note->sender = STRALLOC( sender );

and now it gives this warning,

board.c:908: warning: passing argument 1 of ‘str_alloc’ discards qualifiers from pointer target type

which i can only assume that it has to do with the macro,
#define STRALLOC(point) str_alloc((point))

the ((point)) does that mean that point is being cast? and would changing it to (point) made any difference.

I found it,
char * str_alloc args( ( char *str ) );
in mud.h is what was changing it, can
char * str_alloc args( ( const char *str ) );

i did this and now
note->sender = STRALLOC( sender );

compiles without warnings, but is it correct what i did, or could this actually induce more problems for me than just correcting 1 warning on a cast.
EldhaMUD Game Developments
The_Fury: Lead Developer, Head Coder
http://fury.eldhamud2.org
[Go to top] top
Posted by Robert Powell   Australia  (349 posts)  [Biography] bio
Date Tue 15 Jan 2008 09:19 AM (UTC)  [ quote  ]
Message
This time i am almost 1 step ahead of you, i was just looking over the macros for STRALLOC and friends and working out if i was using the HASH version.

Ill post back in a min with the results of changing what you suggested.
EldhaMUD Game Developments
The_Fury: Lead Developer, Head Coder
http://fury.eldhamud2.org
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Tue 15 Jan 2008 09:14 AM (UTC)  [ quote  ]

Amended on Tue 15 Jan 2008 09:15 AM (UTC) by Nick Gammon

Message
Well it isn't C, it is SMAUG, which implements STRALLOC.

In mud.h:


#define STRALLOC(point)         str_alloc((point))


This means STRALLOC is really synonymous with str_alloc.

Now in hashstr.c we see:


char *str_alloc( char *str );

// other stuff

/*
 * Check hash table for existing occurance of string.
 * If found, increase link count, and return pointer,
 * otherwise add new string to hash table, and return pointer.
 */
char *str_alloc( const char *str )
{
// function implementation here
}


This looks kind of creepy to me. The prototype (first line) defines the input string as non-const, however the implementation (a few lines further) has it defined as const. I would have expected a warning here. I would change:


char *str_alloc( char *str );


to:


char *str_alloc( const char *str );


However that possibly might make other code generate warnings, however it didn't with my version.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Robert Powell   Australia  (349 posts)  [Biography] bio
Date Tue 15 Jan 2008 08:57 AM (UTC)  [ quote  ]
Message
note->sender = STRALLOC( ( char * )sender );

So then with this line its it STRALLOC that does not have const variables, so it needs the cast, which brings up the warning to i can check to make sure what im doing is correct.

Why then does C not come with a version of STRALLOC that has const varialbes so that i could just,

note->sender = STRALLOC( sender );
EldhaMUD Game Developments
The_Fury: Lead Developer, Head Coder
http://fury.eldhamud2.org
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Tue 15 Jan 2008 08:49 AM (UTC)  [ quote  ]
Message
Quote:

Heh, this might be a good topic for one of Nicks Legendary Tutorials.


To be honest, this sort of stuff confuses even experienced programmers, and the C FAQ is a great resource for clearing these things up.

Some of the confusion has arisen because of C's historical treatment of dynamically allocated memory, and arrays of things, as very similar. We often see examples of people trying to do something with static arrays that is best (or only) done with dynamically allocated memory - as an example, you can't "free" a static array.

I think what is happening is that compiler-writers are getting a bit more strict in their error (or warning) checks, with the good intention of helping people detect code that looks good, but is meaningless, or not achieving what you think it is.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Tue 15 Jan 2008 08:47 AM (UTC)  [ quote  ]
Message
Quote:
i think about the only thing i think i know is that you use a const when whats being stored is not expected to change.

Well, that's basically all there is to it, honest. :) It's a safety mechanism, and serves as a statement of intent. By touching a const variable, you are essentially entering a (bendable) contract to not mess with it. Of course, sometimes you need to strip the const annotation. There are two such situations:

(1) for some reason, you want to edit it, even though you're not supposed to. This is very, very unusual, and if it comes up, it might be worth rethinking why you're editing a const variable.

(2) much more frequent: you need to pass something to a function that you know doesn't edit it, but for whatever reason (usually laziness or not knowing any better on the part of the function writer) the function isn't marked as having const variables. Therefore you need to temporarily remove the const keyword with a case.

Of course, in case (2), the compiler (rightfully) complains at you, telling you that you're doing something dangerous. For all you know, that function might modify the data, which is something it really shouldn't do -- and that modification might even cause a crashing bug. (If the data is read-only, and that read-onliness is enforced by the operating system, attempting to write will cause a runtime error.)



I think Nick's explanation of the arg question is very fine so I'll not elaborate on that point. :) I'll just highlight one point which is the conceptual difference between null and zero. Java makes this difference explicit, actually, by marking it a compile-time error to assign null to non-pointers, or zero to pointers.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Robert Powell   Australia  (349 posts)  [Biography] bio
Date Tue 15 Jan 2008 08:43 AM (UTC)  [ quote  ]

Amended on Tue 15 Jan 2008 08:46 AM (UTC) by Robert Powell

Message
Quote:

In particular, do not use NULL when the ASCII null character (NUL) is desired.


Arhh see i did not know that \0 being is the Ascii null, which is what i should look for when working with strings. Yes your analogy clears this up perfectly, while both are zeros they are as different as apples and oranges.

And your post above this clarifies it even further.
EldhaMUD Game Developments
The_Fury: Lead Developer, Head Coder
http://fury.eldhamud2.org
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Tue 15 Jan 2008 08:39 AM (UTC)  [ quote  ]
Message
Quote:

because arg1 is not a pointer. In the above instance its a char.


I am supposing you mean an array of char, because otherwise you can't use the square brackets.

If you have this:


char arg1 [20];

if ( arg1[0] == '\0' ) 
  // do something


That is OK, you are testing one of the bytes inside arg1.

However:


char arg1 [20];

if ( arg1 != NULL ) 
  // do something


Is completely meaningless because arg1 is not a pointer and thus is never NULL.

However consider this:


char * arg1;

arg1 = malloc (100);

if ( arg1 != NULL ) 
  // do something


This is fine, because malloc can fail to allocate memory, in which case NULL is returned. Notice the distinction - the first example used memory on the stack, which must exist, the last example used memory on the heap, which may or may not exist.

See this for an explanation:

http://c-faq.com/aryptr/aryptrequiv.html



- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Tue 15 Jan 2008 08:33 AM (UTC)  [ quote  ]
Message
As a little analogy, if I asked you "how many apples do you have?" and you answered "zero oranges", you might argue that the reply is OK because zero is zero, but I might reply that you have responded with the wrong "type" of fruit.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[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.

8,223 views.

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

[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]