This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH v2] Add <sys/_stdint.h> for FreeBSD compatibility
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: newlib at sourceware dot org
- Date: Tue, 28 Apr 2015 13:06:05 +0200 (CEST)
- Subject: Re: [PATCH v2] Add <sys/_stdint.h> for FreeBSD compatibility
- Authentication-results: sourceware.org; auth=none
- References: <1427875116-12140-1-git-send-email-sebastian dot huber at embedded-brains dot de> <20150401081238 dot GA1957 at calimero dot vinschen dot de> <20150401122815 dot GU13285 at calimero dot vinschen dot de> <20150401184256 dot GE13285 at calimero dot vinschen dot de> <20150428104118 dot GA8675 at calimero dot vinschen dot de>
----- 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.