Register forum user name Search FAQ

Gammon Forum

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 ➜ New Linux, New GCC, New Warnings
New Linux, New GCC, New Warnings

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 3  

Posted by Robert Powell   Australia  (367 posts)  Bio
Date Reply #15 on Tue 15 Jan 2008 08:32 AM (UTC)

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

Message
so, if ( arg1[0] == '\0' ) would be the correct way to do this and if ( arg1 == NULL ) would be incorrect? because arg1 is not a pointer. In the above instance its a char.

Sorry Nick if i seem slow, just making sure that i totally understand what your saying.

Im going now to read those 2 faqs.
Just a guy having a bit of fun. Nothing more, nothing less, I do not need I WIN to feel validated.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #16 on Tue 15 Jan 2008 08:33 AM (UTC)
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
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #17 on Tue 15 Jan 2008 08:39 AM (UTC)
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
Top
Posted by Robert Powell   Australia  (367 posts)  Bio
Date Reply #18 on Tue 15 Jan 2008 08:43 AM (UTC)

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.
Just a guy having a bit of fun. Nothing more, nothing less, I do not need I WIN to feel validated.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #19 on Tue 15 Jan 2008 08:47 AM (UTC)
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
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #20 on Tue 15 Jan 2008 08:49 AM (UTC)
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
Top
Posted by Robert Powell   Australia  (367 posts)  Bio
Date Reply #21 on Tue 15 Jan 2008 08:57 AM (UTC)
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 );
Just a guy having a bit of fun. Nothing more, nothing less, I do not need I WIN to feel validated.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #22 on Tue 15 Jan 2008 09:14 AM (UTC)

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
Top
Posted by Robert Powell   Australia  (367 posts)  Bio
Date Reply #23 on Tue 15 Jan 2008 09:19 AM (UTC)
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.
Just a guy having a bit of fun. Nothing more, nothing less, I do not need I WIN to feel validated.
Top
Posted by Robert Powell   Australia  (367 posts)  Bio
Date Reply #24 on Tue 15 Jan 2008 09:34 AM (UTC)

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.
Just a guy having a bit of fun. Nothing more, nothing less, I do not need I WIN to feel validated.
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #25 on Tue 15 Jan 2008 02:25 PM (UTC)
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #26 on Tue 15 Jan 2008 07:28 PM (UTC)
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
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #27 on Wed 16 Jan 2008 04:44 AM (UTC)
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.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #28 on Wed 16 Jan 2008 05:01 AM (UTC)
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
Top
Posted by Robert Powell   Australia  (367 posts)  Bio
Date Reply #29 on Wed 16 Jan 2008 07:55 AM (UTC)
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?
Just a guy having a bit of fun. Nothing more, nothing less, I do not need I WIN to feel validated.
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.

97,484 views.

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

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home