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