How many developers here are using exact width integer types as defined in C99?
If not why?
thanks ======================= note: This could be by using or by creating your own .h file.
example for typical 32 bit CPU:
/* Exact-width integer types. C99 Standard */ typedef signed char int8_t; typedef signed short int16_t; typedef signed long int32_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned long uint32_t;
I see exact size integers used a lot by those customers that have coding standards and who those that have adopted standards like MISER.
Regards
-- Walter Banks Byte Craft Limited Tel. (519) 888-6911
On Sat, 1 Mar 2008 08:54:18 -0800 (PST), Marco wrote in comp.arch.embedded:
We've used them in all our embedded products since they existed, and pretty much like everybody used equivalents before they were added to the C standard.
I've put together stdint.h equivalents for compilers that do not have them, and included the "least" and "fastest" types as well. That's especially handy on DSPs that don't have 8-bit types at all.
I have written parsers and formatters for communication interrupts using uint_least8_t that build unchanged on DSPs with 16-bit bytes and
32-bit ARM with 8-bit bytes.-- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
I don't. I do, however, use application specific types ie
typedef int ANALOG; typedef ANALOG MOTOR_CURRENT;
Mow the use of strong type checking in lint catches mixing of types, some the use of exact width sizes would not catch.
If I want something like a loop counter I just use int (or concievably long if guaranteed 16 bits is not enough). An exact width type I find in this case overly ornate. Plus they over constrain the compiler ;)
What I do see as potentially useful are the fastest and at_least types but I've nver seen them used.
Perhaps it's just the code I've seen but all the uses of exact width types I've seen have obscured more than they've helped any portability or correctness (who needs a fixed 32bit type to count to 16 for heavens sake!)
Robert
-- Posted via a free Usenet account from http://www.teranews.com
What is this guaranted 16 bits?
A counter is a case where you need to know the size in bits.
Fastest is usually int, that is perhaps why they are not used much.
A typical usage is the definition of structures that must match messages transmitted over a communication link that must be understood by both the transmitter and the receiver. In that case, you must used fixed size types and packed structures. If you want the code to be reused on different architectures, e.g.
8 or 32 bits, it is then an obligation to use fixed size types.
I don't.
Vladimir Vassilevsky DSP and Mixed Signal Consultant
Not very much, unless a customer asks. I know that I'm swimming upstream, but here's my reasons:
Ultimately these 'exact width' integers foster a delusion of exactitude, but they don't provide the real thing. Using char, short, int and long gives me certainty of minimum size (assuming ANSI C), and if I absolutely have to depend on a variable being some exact width then I either mask it myself, use exact width specifiers (with tart comments about non- portability to odd-word-length processors), or put that particular section of code in a file that clearly indicates the limits to portability.
-- Tim Wescott Control systems and communications consulting http://www.wescottdesign.com Need to learn how to apply control theory in your embedded system? "Applied Control Theory for Embedded Systems" by Tim Wescott Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Speaking C, not I. They generally oppose proper portability, and treating integers as holding values. The only real purpose I can see for such things is to know in advance when they will roll over (unsigned) or overflow (signed, leaving undefined results). The values in limits.h do a better and more flexible job.
The definitions given above are not even generally valid.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
It's guaranteed as part of the language. If an int is not at least
16bits you are not using C. It may be sort-of C but t'aint C.Nope, You do need to know the vount variable is big enough but not its exact size. 'Most' loops appear, im my experience to take rather less than 15 bits so int makes sense. If you are space concerned you could use char for those with counts less than 7 bits I suppose.
I suspect it's as much that most people who are using the stdint definitions are not actually thinking about what they need.
There are cleaner and far more portable ways of dealing with such issues. I will freely agree though that cleaniness is pretty much in the eye of the beholder though. The alternate methods also work with items like 10bit packed values, Doing that with fixed sized integers is a little more difficult.
All the code I've seen using this technique was rather paraochial and a touch ugly. It wouldn't even work across different compilers on the same architecture much less anymore widespread.
Robert
-- Posted via a free Usenet account from http://www.teranews.com
I see exact size integers used a lot by those customers that have coding standards and who those that have adopted standards like MISERA.
Regards
-- Walter Banks Byte Craft Limited Tel. (519) 888-6911
I know some automotive authors that are using 24 bit ints. (They have no choice) They are still using type size specific declarations to remind them that the code was written that way and their may be 24 bit assumptions in the code.
Regards,
Walter Banks Byte Craft Limited
Three times lucky
Walter Banks wrote:
I too am a fan of specific types like this (and plenty of enumerated types too). But they mostly boil down to size-specific types rather than general types.
That's part of the C standards.
A counter is often a good example of when you *don't* need to know the size in bits.
There are four reasons I can think of for picking size-specific types. One is to ensure that you have enough bits for all your values - general types like "int" will give you that. A second reason is to ensure that you don't use more bits than you need, conserving ram space. A third reason is when you want exact sizes to fit pre-determined structures, or to make structures into nicely aligned sizes. A forth reason is if smaller data types are faster than the cpu's natural size (think of a
32-bit processor with a 16-bit external bus).But the one time when it really doesn't matter is for local temporary variables, such as a typical loop counter. You might declare it an "int" on an 8-bit micro, but the compiler will (should!) optimise it to a smaller size if that is valid.
Damn, I guess I'll have to remove C programming from my resume then. ;) For the past four years I've been earning a living writing "sort-of" C code where int is 8 bits and long is 16 bits. Before that, there was just as many years where int was 32 and long was 32 and on the other platform int was 16 and long was 32 and before that int was 16 and long was 16.
In response to the original informal survey, yes I do use the exact width integer types all the time. Given that I have to jump across different platforms (sometimes two or three times in one day) I do have to use them or else I would go mad trying to remember which compiler does what. However since not every compiler is C99 compliant I always make my own header file that defines U16 and S16 and U32 and S32 etc.
As for using smaller-than-optimum sized types on a system where the optimum size is larger, the performance hit typically so small that it is negligible. If such a small difference in performance is enough to make or break the system, then your CPU is horribly underspecced for the application. Either re-do the critical loops in assembler or move up to a faster CPU family.
Even with the exact width types I still sometimes screw up because I forgot to add the #$%^ing #pragma pack (1) to the header file; but that's a rant for a different thread.
--Tom.
Yep, only sort-of C ;) It apparently is possible to write a C compiler with proper type sizes on platforms that lead to the temptation to produce compilers since Hi-Tech did do for the PIC. It's also possivle to write C with proper type size and still be aware and use the efficiencies of 8 bit types (you may need to avoid complex expressions though).
Now these are still C. There is no requirement that the size be exactly
16bits, only at least.
Another sort-of but you are introducing enough befores that you may be pre-dating ANSI, although I have seen arguments that the requirement existed in K&R as well.
Yeah, well, pack should be summarily executed ;) but as you said a rant for another time.
Robert
-- Posted via a free Usenet account from http://www.teranews.com
It is a rather minor issue at that point. They are never uses nakedly so whether they exist or whether the known specific sized types for the particular compiler is used when the types are defined is of little significance.
Are there compilers that make that level of optimization?
Robert
-- Posted via a free Usenet account from http://www.teranews.com
I don't know of any compilers that automatically optimize data size. The C standards allow "as if" in most calculations and is usually limited to individual calculations rather than redefining whole variable declarations.
There are lots of compilers including ours that it is possible to redefine the default size of int's and longs.
Regards
-- Walter Banks Byte Craft Limited Tel. (519) 888-6911
What he said.
--
Grant Edwards grante Yow! I'm also pre-POURED
at pre-MEDITATED and
visi.com pre-RAPHAELITE!!
On Sat, 01 Mar 2008 14:11:34 -0600, Tim Wescott wrote in comp.arch.embedded:
Well, yes and no on the portability issue. Unless you never use the types int and unsigned int. If you don't completely bar them from your code, you just might mistakenly use int on a 32-bit processor and it works just fine. Then you move the same code to a 16-bit processor and it breaks when you try to put 100000 into it.
So you always need to use long and short, never int, if you want portability.
Yes, there are architectures widely used in embedded systems, mostly DSPs, that have a byte size of 16, 24, or 32 bits.
That's why the exact sized int types are not required in C99 unless the implementation has those exact width 2's complement types. But the "int_least#_t" and "int_fast#_t" types are required on all implementations, for 8, 16, 32, and 64 bits.
As I said in my reply to the OP, I've written both ends of the parsing and formatting code for CAN (and other binary) communications interfaces, where code has to be pulled out of, or packed into, an arbitrarily aligned octet stream. One end was a 32-bit ARM with 8-bit bytes, the other end a TI 2812 DSP with 16-bit bytes. I used int_least8_t on both sides, and the same code compiles, and runs, on both sides.
I fail to see what you mean by "delusion of exactitude". On a Freescale 56K DSP with 24-bit bytes, none of (u)int#_t exist for 8,
16, 32, or 64 bits. But the (u)int_least#_t and (u)int_fast#_t types do. The exact width type definitions do not exist in stdint.h if the architecture does not natively support the underlying types.It is quite simple to build a usable stdint.h header, in some cases excepting the 64-bit types, for any conforming C compiler all the way back to the original 1989 ANSI standard.
-- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
On Sat, 1 Mar 2008 13:49:54 -0600, "Vladimir Vassilevsky" wrote in comp.arch.embedded:
Actually, the C99 definitions are hardly the most pretty. They have one and only one real advantage, that they are standard and will eventually become widely used.
This is a nice change from every project from every source defining their own, not quite the same, like u8/s8 or U8/S8, or UCHAR/SCHAR, or whatever.
There are two parts to this. The first is that C++ does not, yet, include the C99 stdint.h types, but is already officially approved for the upcoming C++0x update.
The second is that you do indeed need to interface to other people's APIs, and standard library functions, and for this purpose I always add some additional typedefs of my own:
typedef char_t char; /* default char, might be signed or unsigned */ typedef int_t int; typedef uint_t unsigned int;
...and so on.
This serves two purposes. The first is that it avoids MISRA tool warnings about using native types directly. The second is that it stands out in the code as documenting the fact that these values will be interfacing with such APIs.
-- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++ http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.