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

[Corinna Vinschen <vinschen at redhat dot com>]

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?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: pgpTyvIbLMv50.pgp
Description: PGP signature