Re: Getting glibfortran to build on newlib targets aka. missing stdint.h (PR 14325)

[Geoff Keating <geoffk at geoffk dot org>]

On 07/11/2004, at 2:55 PM, Joseph S. Myers wrote:

> On Sun, 7 Nov 2004, Hans-Peter Nilsson wrote:
>
> > Ok, strike the asterisked part.  Should I interpret your answer
> > as an approval of direction generally, for a GCC-provided
> > stdint.h along the directions in PR 448?  Now in stage3
> > (provided it's ok with RM) or next stage1?  (Not providing
> > stdint.h is arguably a bug.)
>
> GCC should provide <stdint.h>.  I think any implementation taking 
> account
> of the points discussed in that bug would be welcome in stage 1 or 
> stage 2
> at least and you should be able to get help identifying what the types
> should be for any targets you don't have access to which already have
> their own <inttypes.h> or <stdint.h>.
>
> > Yes, I read PR 448, but I don't interpret anything there as
> > geoffk being in the progress of implementing it; I just see
> > (good) suggestions.  Not sure it being best with a single
> > "#pragma GNUC stdint" though (i.e. I agree with your #7).
>
> I may have been thinking more of
>
> <geoffk> I'd probably even help, it's been on my list for a while
>
> from the IRC discussion that resulted in comments 6 and 7.

I actually tried to do this, and maybe have a patch somewhere.  It was 
just about to be working when the way we did tokenisation was 
rewritten, and now I don't see how to make it work.

The idea was that you'd have

#pragma GCC stdint
__GCC_STDINT__

as the entire contents of the header.  The #pragma would look at the 
currently-defined macros and then define the macros that stdint.h 
requires, plus __GCC_STDINT__ which would contain a long list of 
'typedef <some type> <some name>;'.  I am not sure about the wisdom of 
the __GCC_STDINT__ part, but that wasn't the part I was having trouble 
with; the problem is that after the rewrite, all #pragmas get processed 
after macros are expanded, which is way too late for this.

> > >  Also note the other comments in that
> > > bug (e.g. as regards using C99+TC1, not plain C99).
> >
> > Will I find TC1 at the same official channels I acquired a copy
> > of C99?
>
> ISO and IEC should send the PDF of TC1 free of charge (and maybe 
> printed
> copies).  TC2 was sent to National Bodies for ballot and approved but I
> don't know how well any public draft corresponds to the version 
> balloted.
> The <stdint.h> changes in TC2 add a requirement that the exact-width 
> types
> have no padding bits and two's complement representations (true for all
> GCC-supported targets) and permit freestanding implementations not to
> define limits for wint_t and sig_atomic_t if they don't have a notion 
> of
> such types (but GCC does always have an internal notion of wint_t, 
> though
> it hasn't yet needed to know about sig_atomic_t).

One part of the exercise is to design a convenient way for the target 
to override the default for each of the types, including sig_atomic_t 
(which should probably default to intptr_t or 'long').

Attachment: smime.p7s
Description: S/MIME cryptographic signature