Subject: Re: ansi.h merger
To: None <tech-ports@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: tech-ports
Date: 07/28/2001 16:01:01
In article <Pine.WNT.4.33.0107280036150.476-100000@todd>,
Todd Vierling <tv@wasabisystems.com> wrote:
>
>* Lint is currently **broken** on a toolchain built from the gcc 2.95.x
>  sources, because the hacks for LINTCOMMENT that we added have not been
>  ported to gcc 2.95.x.  Once that's done, come back and talk to me.  :)

That is not relevant to the proposal.

>* With the above in mind, any warnings and errors in gcc and/or lint that
>  talk about typecasting problems for printf format strings,
>  <machine/ansi.h> type conversions, etc. are actually correct:  that is
>  broken, nonportable code that must be fixed, because the <machine/ansi.h>
>  types do not have fixed correlations to primitive integer types (they are
>  platform-defined in C99).

The code cannot be made portable easily (without breaking existing api's etc.,
or by sweeping changes).

>  sommerfeld did a printf() format audit last year, for instance, and adding
>  -Wformat=2 in gcc 2.95.x should provide most of this same format checking
>  to warn on all platforms when an unportable construct is used.  There are
>  some other -W options that may help here, too.

It is a problem when you have an int that you are passing in a size_t
parameter argument. consider:

    strncpy(foo, bar, 13);

Well, is that 13U or 13UL? Or should I need to cast it to (size_t)13?

>This is not a problem.  The correct fix to any of this is to fix the broken
>code so it is portable as defined by C99.  There's dozens of methods that
>are explicitly listed there to assist in such fixing.
>

But why keep the types in <machine/ansi.h> MD, when they can be made MI?

christos