Usage of INT_MAX, etc.

Thiago Macieira thiago at
Wed Oct 25 17:37:43 BST 2006

Jaroslaw Staniek wrote:
>I am sorry, I'd like to talking about all the integer datatypes (hence
> the "etc." in the "Usage of INT_MAX, etc." subject), and maybe floating
> point (long double) is also affected. Sorry about choosing wrong
> example. Talking about 'long's is better.
>So: sizeof(long) is 8 under IA64 and 4 under powerpc (KDE is available
> there on Linux and will be on MacOSX)
>i.e. LONG_MAX/LONG_MIN/ULONG_MAX/ULONG_MIN are affected. I haven't
> checked all the combinations yet.
>Since the only constraint is that LONG_MAX >= 2147483647, LONG_MAX >=
> INT_MAX, this could help:
>  #define LONG32_MAX 2147483647L

What is a long32? Is that a long for when long is the same size as an int? 
If so, why not use INT_MAX?

And, like it's been said, the constants are only useful if we don't know 
the size of a type. Since we know that this type is 32-bits in size, we 
know its limits.

>The main reason I'd like to have it is to get clearly defined limits for
>applications that allows the user to select data types (Kexi is one of
> them, and various database environments are other) - otherwise it is
> even risky to fetch the data from the database/file.

The database type limits are generally enforced and defined by the 
database backend, not by the application. A SMALLINT in one DB could be 
of a different size than the same name in another DB, or so I understand.

My point is: I still don't see the use-case for these constants. If you 
know they are 32 bits in size, you know the limits. Or are you worried 
about people mis-typing the value?

  Thiago Macieira  -  thiago (AT) - thiago (AT)
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list