[PATCH v2] Add <sys/_stdint.h> for FreeBSD compatibility
Corinna Vinschen
vinschen@redhat.com
Tue Apr 28 21:27:00 GMT 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150428/724b8317/attachment.sig>
More information about the Newlib
mailing list