Re: [PATCH v2] Add <sys/_stdint.h> for FreeBSD compatibility

[Corinna Vinschen <vinschen at redhat dot com>]

On Apr 28 13:06, Sebastian Huber wrote:
> 
> ----- Corinna Vinschen <vinschen@redhat.com> schrieb:
> > On Apr  1 20:42, Corinna Vinschen wrote:
> > > On Apr  1 14:28, Corinna Vinschen wrote:
> > > > On Apr  1 10:12, Corinna Vinschen wrote:
> > > > > On Apr  1 09:58, Sebastian Huber wrote:
> > > > > > v2: Move also intptr_t and uintptr_t.
> > > > > 
> > > > > Thanks.  I still didn't manage to complete my testcase but I *am*
> > > > > working on it :}
> > > > 
> > > > Ok, I managed to do my test.  The patch looks good.  However, there's
> > > > one point I'd like to discuss.
> > > > 
> > > > The Cygwin stdint.h defines all the MIN/MAX values with enclosing
> > > > parens, just like GLibc's stdint.h does.  Shan't we do the same in
> > > > newlib's stdint.h?  It might not really necessary, technically, but
> > > > it looks cleaner somehow.
> > > 
> > > Patch applied.  I added the parens in a followup patch.
> > 
> > Oh well.  I managed to miss a problem during testing.  We just got a
> > report on the Cygwin mailing list.
> > 
> > The 32 bit types (e.g. int32_t, uint least32_t) on 32 bit i686 Cygwin,
> > are defined as "int".  However, the tests in sys/_intsup.h lead to the
> > definition of __have_long32 to 1, which in turn results in using long
> > constants in stdint.h and inttypes.h for 32 bit macros.  And this in
> > turn results in GCC warnings:
> > 
> >   printf("int = %"PRId32", uint = %"PRIu32".\n", ival, uval);
> >   ^
> >   x.c:9:9: warning: format â%luâ expects argument of type âlong unsigned intâ,
> >   but argument 3 has type âuint32_tâ [-Wformat=]
> >   x.c:9:9: warning: format â%ldâ expects argument of type âlong intâ, but
> >   argument 2 has type âint32_tâ [-Wformat=]
> > 
> > On second thought, the definition of __have_long32 in sys/_intsup.h
> > always prefers "long" over "int", no matter how GCC actually defines the
> > base types __uint32_t, etc.
> > 
> > So the question is, shouldn't we use the same new method we're using
> > to find the right definition for {u}intptr_t for the {u}int32_t types
> > as well?
> 
> I think the problems are not the type definitions, since they use the
> GCC builtin defines.  The problems are the print macros for which no
> GCC builtin defines exist.

Yes, I meant that.  Sorry if my wording was fuzzy.  I just sent a patch
proposal.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpQ_He0QxcCj.pgp
Description: PGP signature