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 ➜ Question on ints and long ints

Question on ints and long ints

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


Posted by Nick Cash   USA  (626 posts)  Bio
Date Sat 10 Jan 2004 07:41 AM (UTC)
Message
I was just wondering this for a while and so I decided to post the question here. As I've delt with it before, and how it is on my C programming book, it says int goes up to 32,767 or something close (not sure if thats the exact number off the top of my head). So my question is this, why do the millions/billions vnum snippets for smaug change all sh_int to ints? Is it different in smaug? To get billions of vnums wouldn't they need to be long ints?

Just a question. Thanks in advance.

~Nick Cash
http://www.nick-cash.com
Top

Posted by Dave   Australia  (93 posts)  Bio
Date Reply #1 on Sat 10 Jan 2004 08:32 AM (UTC)

Amended on Sat 10 Jan 2004 08:33 AM (UTC) by Dave

Message
The standard size of an 'int' defaults to the 'word size' of the architecture, and the word size is usually the same as the register size of the CPU, but not always. So if a system has a 64 bit CPU, and the CPU has 64 bit general purpose registers, then an 'int' will pretty much always be 64 bits, but this is not guaranteed. For example, on the sparc64 platform, the compiler may opt for 32 bit binaries, which means you get 32 bit ints, pointers, etc, even though the general purpose registers are 64 bits, so essentially, the size of an 'int' is horribly unreliable and should never be taken for granted if you want to maintain some sort of portability.
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #2 on Sat 10 Jan 2004 10:20 AM (UTC)
Message
On the other hand, a short int (sh_int) is generally guaranteed to be 16 bytes in size, so that's why it gets rid of short. However, Dave is right in that technically speaking the size of "int" is unreliable, and you should be using a long instead.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #3 on Sat 10 Jan 2004 07:18 PM (UTC)
Message
Quite right - in fact to get a guaranteed size the billion number vnum should really use "long" not "int", as Ksilyan said.

Your system should have a file limits.h somewhere, in it are the limits for your particular case, like this:


#define SCHAR_MAX       127             /* min value for a signed char */
#define SCHAR_MIN       (-128)          /* max value for a signed char */

#define UCHAR_MAX       255             /* max value for an unsigned char */
#define CHAR_MAX        127             /* max value for a char */
#define CHAR_MIN        (-128)          /* min value for a char */

#define USHRT_MAX       65535           /* max value for an unsigned short */
#define SHRT_MAX        32767           /* max value for a short */
#define SHRT_MIN        (-32768)        /* min value for a short */

#define UINT_MAX        0xffffffff      /* max value for an unsigned int */
#define INT_MAX         2147483647      /* max value for an int */
#define INT_MIN         (-2147483647-1) /* min value for an int */

#define ULONG_MAX       0xffffffff      /* max value for an unsigned long */
#define LONG_MAX        2147483647      /* max value for a long */
#define LONG_MIN        (-2147483647-1) /* min value for a long */


You can see that in this case an int and a long both have the same size (2147483647) which is effectively slightly over 2 billion.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Cash   USA  (626 posts)  Bio
Date Reply #4 on Sat 10 Jan 2004 08:17 PM (UTC)
Message
Alright. Thanks for confirming my thoughts. :)

~Nick Cash
http://www.nick-cash.com
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.


15,129 views.

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.