Mail Archives: djgpp/2004/03/06/14:30:52
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
- Raw text -