This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


----- 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.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]