Various software sizes calculation

Ralf Corsepius ralf.corsepius at rtems.org
Sun Oct 11 08:03:03 UTC 2009


On 10/11/2009 08:38 AM, Andrei Chichak wrote:
>
> On 2009-October-10, at 8:19 PM, Aaron J. Grier wrote:
>
>> On Tue, Oct 06, 2009 at 11:05:21AM +0200, Thomas Doerfler wrote:
>>> But in various applications size matters. So if you have let's say
>>> 128KByte of RAM in your (space?) system and you need an answer to the
>>> question "which data types might be appropriate if I want to save an
>>> array of 16000 measured data samples" then getting this information
>>> may be quite important. ok?
>>
>> isn't this what the stdint.h types are for? uint32_t, int8_t, etc.
>
> Sorry to chime in, but ABSOLUTELY!

Yep.

> One of my standard things is to define, and check the size of, CHAR,
> BOOLEAN, INT8U, INT8S, INT16U, INT16S, INT32U, INT32S, INT64U, INT64S,
> FP32 and FP64, with code like:
[..]
> This will cause a compile time error if the sizes are not as expected.
Feel free to use such code, but I don't agree to finding this "clever" ;)

> uint32_t and such only came around in C99
<sarcasm>
Yes, they are only ten-years old and had been around in many 
implementations for very much longer ...
</sarcasm>

=> Nowadays, there is hardly any reason for not using them in new code.

> and still aren't being adopted
> by the industry. C# actually discourages such things right in their
> style guidelines, preferring to use ints (but then again they also
> prefer not to put braces around single line ifs...dangerous habits).
Well, such advice is somewhat narrow-minded.

IMO, it depends on the use-case. In high-level applications, one rarely 
needs any fixed-size-types and is better off not using them.

In low level code (RTEMS, kernels, drivers) things are quite opposite.
If you want such code to be portable, you hardly can't avoid to care 
about sizes.

Wrt. RTEMS, stdint.h types are the way to go "__when really needed" and 
to avoid them "when ever possible".

> Also, int8_t doesn't explicitly indicate its signedness, it is still
> open to interpretation.
Not quite: intX_t's are mandated to be signed:

c.f.:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

Ralf



More information about the users mailing list