Re: [avr-libc-dev] [RFC] more -mint8 changes for pgmspace.h

[Theodore A. Roth]

On Wed, 17 Sep 2003, E.Weddington wrote:

> > > > Objections?
> > >
> > > Not really. But while you're at it, instead of your
> FIXME,
> > > why not replace the prog_[int,long,long_long] with your
> > > definitions:
> >
> > That was my intent after some feed back. Like I said
> previously, I'm
> > not sure what the exact purpose of the prog_* typedefs
> are.
>
>
> I think for completeness.
>
>
>
> <snip>
>
> > No. The (u)int64_t typedefs are not affected by -mint8_t
> (see
> > inttypes.h) so can stay defined. The only reason for
> #if'ing out the
> > (u)int32_t typedefs is to avoid having the header barf
> because
> > (u)int32_t is not defined when using -mint8.
> >
>
> Ok, I'm opening up the can of worms again.
>
> See this: <http://mail.nongnu.org/archive/html/avr-libc-
> dev/2002-11/msg00111.html>
> and related thread.
>
> There was agreement by Ted and Jörg (and no disagreement
> from Marek per se) about the patch in the above message
> which changes avr-gcc to have a 32 bit type in -mint8 and
> to drop the 64-bit type in -mint8. It seems that there is
> agreement that this makes more sense than the current setup.
>
> I would rather get this patch in to GCC (Hello, Denis?) and
> keep the 32 bit pgmspace macros for -mint8. So, yes, I have
> some objections.

That's a moot point. avr-libc-1.0 is bound to gcc-3.3.x. The patch for
gcc shouldn't go into the 3.3 branch at this point. Having those
macros defined is broken under the current implementation. We can
bring them back in the 1.1 cycle if gcc-3.4 includes the patch which
means we bump the major version number to 2 and bind avr-libc-2.0 to
gcc-3.4.

>
> Oh, and btw, shouldn't -mint8 be documented somewhere in
> the GCC manual?

Of course.

Ted Roth