X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Trace-PostClient-IP: 68.147.131.211
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT Invalid>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: 16 bit integers
Organization: Systematic Software
Message-ID: <1l9k40p19p5mev2pn00nsn6sh7qljlr51u@4ax.com>
References: <baec0bf0 DOT 0403012323 DOT 10896c3 AT posting DOT google DOT com> <esd840d8dde7matafu4vd11bsvagshadkl AT 4ax DOT com> <baec0bf0 DOT 0403020529 DOT 8f42598 AT posting DOT google DOT com> <Xk01c.25898$aZ3 DOT 23018 AT fed1read04> <4045a682$1 AT news DOT infonet DOT ee> <8d4d405go3mm3kvb70drkoat31ukdep52o AT 4ax DOT com> <404705d5$1 AT news DOT infonet DOT ee> <dn6f40ha2iqdibf6uldjgh3rsdkd2e4vvq AT 4ax DOT com> <40485780$1 AT news DOT infonet DOT ee>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 118
Date: Sat, 06 Mar 2004 19:29:42 GMT
NNTP-Posting-Host: 24.71.223.147
X-Complaints-To: abuse AT shaw DOT ca
X-Trace: pd7tw2no 1078601382 24.71.223.147 (Sat, 06 Mar 2004 12:29:42 MST)
NNTP-Posting-Date: Sat, 06 Mar 2004 12:29:42 MST
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Fri, 5 Mar 2004 11:03:29 +0200 in comp.os.msdos.djgpp, "Tõnu Aas"
<tonu AT ids DOT ee> wrote:

>> >> Portable assumptions are: char holds at least 8 bits, int at least 16,
>> >> long at least 32: pick the appropriate size for the range of integers
>> >> you have to deal with. Avoid C99 stdint.h if you want to be portable
>> >> to most existing implementations.
>
>> Are you trying to imply the types defined in stdint.h are more
>> portable than char, int, long?
>    Yes, because int and long are not portable. Even char can be not
>portable.

They are portable if you understand just what the Standard guarantees.

>You cant just write for(int i = 0; i < 66000; i++) isnt it ?

But you have always been able to write:
	for (long l = 0; l < 66000L; ++l)

>You cant even write for(int i = 0; i < 300; i++) in some case on embbeded
>systems (o.k. thats another case).

The latter is non-Standard and non-portable: the standard guarantees a
*minimum* of 16 bits. 

>    Look around and you see that every library or package starts with
>defining "their own types":
>WORD u_int, int16 ...
>And you are saying that you havent any trouble with using more than one
>library because
>they define basic types differently ?

They do that because that is the proper approach to portability,
although their choice of type names is pathetic. 

>> If you use the stdint.h definitions, maybe you should include the
>> header with your code to ensure portability.
>> That saves others the trouble of making up their own, or editing your
>> types back to the base t0ypes.
>
>The only thing they must do is to make stdint.h, what makes sense on their
>plaform.
>(if this platform doesnt have stdint.h) Thats all.

The header stdint.h is Standard, but the types are *optional*. 
A zero length stdint.h is strictly conforming, OTOH I don't believe
that any programs using optional types from stdint.h are strictly
conforming, as the ability to compile, never mind behaviour, is
implementation dependent. 

>> Do you really see an advantage to using int_least16_t or int_fast32_t
>> where int and long would do?
>
>    Not everybody writes "Hello world" type programs.
>If you program must work on DOS, Windows, Linux and washing machine and
>you must interfere with some harware or OS API, then you code will be full
>of
>int64_t, int16_t, uint8_t ...

These types are reserved by the Standard for *optional* integer types
with special properties, which may not be present on a platform, so
third party library developers will still not use them. 

>> AFAICT stdint.h is intended for use in circumstances where particular
>> integer characteristics are required for particular reasons in
>> portable code.
>
>> OTOH I expect most compilers to just treat them the same as the base
>> types, so in that case what have you gained in terms of code clarity,
>> efficiency, and portability?
>
>???  If you see int16_t, then its clear, that 16 bit integer used.

Not necessarily, only if the type is available, as stdint.h and all
the types in it are *optional*: see below for updated definition. 

>If you see:
>#if INT_MAX == 0x7fff
>int  offset;
>#elif INT_MAX == 0x7fffffff
>short int offset;
>#endif
>- is it clear for you ? Yes there are lots of librarys full of this type
>"clarity".

I assume you meant to include limits.h and have typedefs of offset, or
is offset meant to be a variable: in the latter case, that is
extremely bad practice, and that is a library QoI problem. 

>    Portability gained from using one and only header to gain portability.
>Thing are even worse in C++ where 32 bit int is not the same as 32 bit long
>int.

On the *optional* integer types in stdint.h, quoting from a recent
post in comp.std.c:

"This was addressed in DR #269, for which the committee has
approved a technical corrigendum (not yet official, but
indicative of the intent):

Change 7.18.1.1#3 to read:
	These types are optional. However, if an implementation
	provides integer types with widths of 8, 16, 32, or 64
	bits, no padding bits, and (for the signed types) that
	have a two's complement representation, it shall define
	the corresponding typedef names."

So some of these type names will not be defined on various platforms
from embedded chips to DSPs to some RISCs, where the exact width type
may not be supported, although char, int, long will still be available
and work. 

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian DOT Inglis AT CSi DOT com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply