Usage of INT_MAX, etc.
thiago at kde.org
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) macieira.info - thiago (AT) kde.org
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel