Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs are incorrect

[Joerg Wunsch]

Volker Kuhlmann <address@hidden> wrote:

> Your analysis tool is correct in not having uintX_t predefined. K&R
> quite clearly says that they are defined in a lib header file.

Note that "R" in the K&R meanwhile died, and I doubt he contributed
much to the C99 standard.  "K&R", in terms of standardizing C, usually
refers to the pre-ANSI C89 de-facto standard.

You've clearly got a completely wrong understanding of the way the C
standard works.  The standard mandates that the respective identifiers
are declared or defined by the respective header file, but it does not
make any claims about *how* an implementation defines or declares
them.  So it's completely sufficient for a static analysis tool to
recognize the #include <stdlib.h> statement, and then assume all those
identifiers that are described in the standard are defined with
exactly the effect that is described in the standard.  Anything else
is asking for trouble.

To pick a completely different example, how on earth would an analysis
tool want to handle the stuff from <stdarg.h>?  The va_arg macro has
to invoke some `magic' to get the next argument from the list, which
could be located in a CPU register, or on the stack, depending on the
target machine and the way the implementation of variadic arguments
has been made.  The answer is quite simple: as soon as <stdarg.h> has
been included, the tool has to assume that va_arg, used in the way as
described by the standard, just does what it is intended to do.

I've already quoted the way newer GCC versions provide their own
stdint.h.  If an analysis tool wants to track each of the declarations
there, it will yield none of them, as the header file all resolves
them into internal macro names, properly #ifdef'ed.  The tool won't
have any of those predefined (they are internally defined in GCC, to
the appropriate type names), and thus would (incorrectly) treat all
these as being undeclared.

In fact, if it turns out that already GCC 3.x declares macros like
__INT8_TYPE__ etc., I tend to change the avr-libc header file to
exactly the same magic as the newer GCC header files have.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)