Subject: Re: ansi.h merger
To: Christos Zoulas <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 07/28/2001 12:18:59
[Again moved to tech-toolchain, I didn't notice that tech-ports had been
replaced in the Cc: header.]
On Sat, 28 Jul 2001, Christos Zoulas wrote:
: >* 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).
Huh? Unless you have a specific counterexample, all cases where the
compiler is warning about type conversion portability problems are perfectly
correct in their assertions.
: 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?
C99 type conversion rules allow this case to be promoted without a warning,
because the default case of nonnegative "int" constant can be promoted to
"unsigned int" and then "unsigned long" automatically.
The things Eduardo has been talking about mainly deal with things like
printf() format arguments. These *must* be casted if they are not primitive
types, or sized types with #define macros in our <machine/int_fmtio.h>; this
is nonnegotiable, and encouraging sloppy code is just wrong.
: But why keep the types in <machine/ansi.h> MD, when they can be made MI?
Not all can be made MI, mind you. I found clock_t as one such type already,
but I haven't scanned through everything.
-- Todd Vierling <firstname.lastname@example.org> * Wasabi NetBSD: Run with it.
-- NetBSD 1.5 now available on CD-ROM -- http://www.wasabisystems.com/