Re: Portable type definitions for tools

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Wed, Sep 10, 2008 at 09:22:12PM +0200, Alan Barrett wrote:
> On Wed, 10 Sep 2008, Joerg Sonnenberger wrote:
> > can you please review the attached patch for configure.ac and friends?
> 
> I asume that this for src/tools/compat.

Yes.

> > Not included is configure itself as it is 300KB by itself due to the
> > different version.
> 
> Are you using the nbautoconf that gets built with MKMAINTAINERTOOLS=YES ?

Hm. I guess I was missing that part.

Is there a good reason to have an ancient autoconf for this purpose?
I could of course port the macros, but that would defeat part of the
purpose.

> > (b) It defines u_int{8,16,32,64}_t to uint{8,16,32,64}_t if the former
> > don't exist.
> 
> Why do you want (b)?

Newer autoconf can properly compute fixed size types. This doesn't help
the various places that still require the BSD types.

> >  CPPFLAGS+= -I. -I./include -I${.CURDIR} -I${.CURDIR}/sys \
> > +           -I${.CURDIR}/../../common/lib/libc/stdlib \
> >             -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64
> 
> Why do you need that "-I" flag?

strtoimax.c doesn't find _strtol.h otherwise. Other approach would be to
just move that to common as well, I wouldn't be surprised if that is
useful in kernel land later.

> Do we have tools that rely on u_intNNT?  If so, I think we should fix
> them to use uintNN_t instead, and rip these definitions out of the
> compat headers.

Lots of src/include (parts still used by toolchain) and e.g. libc still
depend on it. I agree that we should stop depending  on that, but it is
work. This is an intermediate step to just hack them up more cleanly.

Joerg