Usage of INT_MAX, etc.

[Jaroslaw Staniek]

Thiago Macieira said the following, On 2006-10-25 18:37:

>>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? 

It is only the same as int if sizeof(int)==4. Hmm, to be compatible with Qt4, 
maybe I should use INT32_MAX. See (*) below.

> If so, why not use INT_MAX?

Because INT_MAX tells you nothing about # of bits when you read the code. Even 
if someone knows the standard, # of bits is >= 32. You mentioned it is == 32 
on KDE-supported targets, so I added the example about long integers.

In a typical API methods 'int' means "big enough integer type". There is 
remaining small percent of code in various apps that could not assume this.

LONG_MAX != INT_MAX. LONG_MAX can be 0x7FFFFFFFFFFFFFFF on some systems. If I 
use int32, I know it's 4 bytes. If I use long I don't know this.

We're talking about code using at least qglobal.h, so compatible, convenience 
defines can be:

(*)
#define INT32_MAX std::numeric_limits<qint32>::max()
#define INT64_MAX std::numeric_limits<qint64>::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.

See (**) below

> 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.

Types of a db server and db client's types are the same, what affects directly 
the app using the client. E.g. when we want to convert 8 bytes to a long 
integer value (e.g. fetched to mysql's char*), using int64 is safe and 
longlong is not.
Then, e.g. in other code reading numbers from a data stream, checking the 
input against INT64_MAX and INT64_MIN could be a bit more clear, before the 
values are saved back to the db.

> 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?

(**) I am worried that 2147483647L tells nothing in the header file (or at 
least you need to think two seconds about its meaning).

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org