Re: Delay Routine: Fully-portable C89 if possible



David:

*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-co
arrays). Even nominally C89 compilers frequently support such features.


There's nothing at all wrong with extra features, so long as they
don't alter the behaviour of fully-standard-compliant programs or
prevent them from compiling successfully.


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.


I do indeed write my code to a quality standard, and that standard
finds nothing wrong with "unsigned". The majority of good C
programmers leave out the redundant keywords unless they really wanna
be explicit about what they're doing. When was the last time you saw
"auto" in a C file? Or even in the real world, who writes a plus sign
behind positive numbers?


Secondly, I was suggesting that if you want portable code, you have to
use size-specific integer types.


Nope definitely not, you just have to be guaranteed to have a given
range with the type. For example:

short unsigned : at least through 65535
long : at least -2147483647 through 2147483647


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.


Again I contest the need for this.


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.


The microcontroller I'm using currently has 6-Bit ports but 8-Bit
registers and memory chunks... still no problem though.

Martin

.