Re: Delay Routine: Fully-portable C89 if possible

John Devereux wrote:
Martin Wells <warint@xxxxxxxxxx> writes:

David:

Most
importantly, it gives you "stdint.h" and types like "uint32_t" so that
you can avoid unspecific non-standardised types like "long unsigned"
(which should always be written "long unsigned int").
"long unsigned int" is a part of C89.

Perhaps you were on about "long long unsigned int"? (which is a part
of C89 but not C99)

As far as any compliant C89 compiler is concerned, "long unsigned" and
"long unsigned int" are the same thing. If the compiler doesn't accept
it, then it isn't a C89 compiler.

Even if it were worth switching to C99 (which I don't think it is), I
still wouldn't because it's so poorly implemented today.

*All* C standards are implemented to varying degrees, and *all* embedded compilers add their own extensions. Take advantage of what you get (such as <stdint.h>, inline, and // comments), and leave out the parts that are poorly or inconsistently implemented (such as variable length arrays). Even nominally C89 compilers frequently support such features.


No, he is saying that he prefers being able to use uint32_t, instead
of, for example, long unsigned.


Actually, I was saying two things (without making that very clear).

First the simple part - omitting the "int" part of declarations and definitions is an abomination brought about by the terrible keyboards K&R had to work with when developing C. The type in question is called "long unsigned int" - "long" and "unsigned" are type qualifiers. The language standards say that if a type is expected, but you haven't given one, then an "int" is assumed, and any C compiler will accept that. But the compiler will accept all sorts of hideous code and generate working results - you have to impose a certain quality of code standards if you are going to write good code. One of these rules is that if you mean a type should be "int" (optionally qualified), then you write "int". If you don't want to write out "long unsigned int", then use a typedef.


Secondly, I was suggesting that if you want portable code, you have to use size-specific integer types. Using <stdint.h> is an easy way to get that - otherwise, a common format header file that is adapted for the compiler/target in question is a useful method. It doesn't really matter whether you use "uint32_t" from <stdint.h>, or have a "typedef unsigned long int uint32_t" in a common header file - nor does it matter if you give the type your own name. But it *does* matter that you have such types available in your code.


Certainly many of the situations where size specifics are important are in hardware dependant and non-portable - and thus the only issue is that the code in question is clear.

But there are many cases where you need a minimum range which may not be satisfied by "int" on every platform, and also where you want the fastest implementation. If you have a function delayMicrosecs(unsigned int n), then the useful range is wildly different on a 32-bit target and a 16-bit (or 8-bit, with 16-bit int) target. On the other hand, if it is declared with "uint32_t n", it is portable from 8-bit to 64-bit processors. Since the OP was asking for portable code in an embedded newsgroup, there's no way he can make assumptions about the size of "int".

mvh.,

David



I personally don't agree though. At least in my own work I have not
found a real-life situation where these types are an
improvement. Basically, if you are worried about the exact widths of
types, then that part of the program is likely non-portable anyway, so
the new types don't help much.

For example, in C99 I could define a 32 bit hardware register like
this:

#include <stdint.h>
#define PORT (*(volatile uint32_t *)(0x1FFF0000))

But in fact this code will likely be useless on some hypothetical
other CPU anyway. I can just as easily rely on ints being 32 bit on my
platform, and do

#define PORT (*(volatile unsigned long *)(0x1FFF0000))


.

Relevant Pages

  • Re: It Pays to Enrich Your C Skills
    ... Check if you can score a perfect 10 (without using a compiler). ... int main{ ... struct bitfield { ... out if it is a negative integer constant or a constant expression ...
    (comp.lang.c.moderated)
  • OT: Re: Perl Peeves
    ... I see the result of a test being used as an int. ... the compiler just assumed you knew what you were doing ... introduced to the language later, so void * was unheard of in most code. ... This didn't mean bool was special, declaring it just signaled to the ...
    (comp.lang.perl.misc)
  • Re: OT: Re: Perl Peeves
    ... when I see the result of a test being used as an int. ... compiler just assumed you knew what you were doing and would ... This didn't mean bool was special, declaring it just signaled to the ... What "normalization of bool results is built into the compiler"? ...
    (comp.lang.perl.misc)
  • Fwd: Xlib example program compile error
    ... Here is the compiler output for xctest.c as it is written in the book. ... xctest.c:163: `theMain' undeclared ... XWIN *MakeXButton(int x, int y, unsigned height, unsigned bdwidth, ... Window parent, char *text, int, ...
    (comp.os.msdos.djgpp)
  • Re: cpu type idea
    ... compiler related recently. ... int main ... float a; ... just to parallelize the vectror and tensor operations. ...
    (alt.lang.asm)