Re: Delay Routine: Fully-portable C89 if possible


*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.



Relevant Pages

  • Re: subroutine stack and C machine model
    ... the most fundamental facts about C right, *why should I listen to you*? ... Firstly he was not the only person on the standards committee, secondly he probably was not the most influential person on it, and thirdly it is only you who thinks a lot of the things you pick on should be changed. ... The programmers I know all have more sense than to rely on order of evaluation within an expression *whatever* language they are programming in, since it makes it harder for *people* to follow what is going on. ... but most compilers don't seem to prevent it. ...
  • Re: Implicit int
    ... reducing bad programming practices in the future (including ... What is the necessity of long long when long int, ... Is this decision taken because *many* ILP32 compilers (which are ... Why should the standards care if a particular implementation is not ...
  • Re: Some thoughts for the future
    ... WordPerfect from Canada was developing an OS that could run either Linux ... Linux does not seem to be held by standards as much as other OSes, ... efficient compilers and more efficient source code to be desirable. ...
  • Re: so forth is useless except for limited mem environments?
    ... follow the coding standards an employer or customer imposes. ... There were enthusiastic C programmers ... Now the TIOBE measure says that Java is ... and very fast C compilers for some processors. ...
  • Re: Why the size of the VC++ produced binary is so huge?
    ... > try to hook up other compilers to VS environment). ... offset as your program gets larger, not a ratio (i.e. on a 16Mb EXE image, ... the VC image might still be 70K bigger, but it won't be 18Mb bigger. ... size difference probably mostly equates to differences in standards ...