This is the mail archive of the
mailing list for the newlib project.
Re: Regression with printf 8-bit format macros
- From: Andre Vieira <Andre dot SimoesDiasVieira at foss dot arm dot com>
- To: newlib at sourceware dot org
- Date: Mon, 4 Jan 2016 11:21:59 +0000
- Subject: Re: Regression with printf 8-bit format macros
- Authentication-results: sourceware.org; auth=none
- References: <CAOA3yK+__aWFL8KHUUEuPYGNCjAsXBeRDKpgWQEzYj3YrXNOxA at mail dot gmail dot com> <2655776 dot nuc1R7VGlh at infernus> <CAOA3yK+k8m1ub30X4ngjYhtEHg5L4bEQLFZPKwCYRhCMQjK86g at mail dot gmail dot com>
Just to clarify as to why this change was made. The PRI*8 and SCN*8
macro's were printing '*' before, the pattern for 32-bit types, when the
actual size of __INT8_TYPE__ was '8 bits', i.e. _WANT_IO_C99_FORMATS was
defined. Which we agreed at the time was the wrong behavior.
Now you are not the first to stumble onto this issue, though as FCh
points out these are C99 types and the configurations you mentioned do
not support these.
On 01/01/16 23:03, Ambroz Bizjak wrote:
I do agree that it is weird that for the SCN*8 macros to be guarded with
_WANT_IO_C99_FORMATS, whilst the PRI*8 are not. Though guarding PRI*8
would not solve your problem, as you seem to want these to be defined as
'*', i.e. defaulting to their earlier behavior of returning the 32-bit
format pattern. I would oppose doing this in all cases, since if
_WANT_IO_C99_FORMATS is defined, then this would yield the erroneous
behavior this patch was meant to fix.
I hope we agree that C99 support should not be an all-or-nothing
decision, you should be able to have some parts (like the stdint types
which cost nothing), but not other parts like the full C99 support in
printf. The worst part really is that the PRI*8 macros are defined in
the mentioned configurations but they do not work. I see that on the
other hand the SCN*8 macros are not defined when they would not work
(see the top comment in inttypes.h).
There might be a case to be made for doing so if _WANT_IO_C99_FORMATS is
not defined. On the other hand, doing this for SCN*8 would be a bad idea
in my opinion and this would keep the discrepancy between PRI*8 and SCN*8.
I do not think we should encourage the use of PRI*8 and SCN*8 types if
these are not supported by the library being used. As this seems to be
the case, since _WANT_IO_C99_FORMATS is not defined, which I think would
be the appropriate macro to indicate support for such.
But then we can have the PRI*8 macros for free anyway, so why should
they be available only when printf has "hh" support?
On Fri, Jan 1, 2016 at 11:44 PM, Freddie Chopin <firstname.lastname@example.org> wrote:
On piÄtek, 1 stycznia 2016 12:08:30 CET Ambroz Bizjak wrote:
It appears to me that commit "Fix for pri and scn formats"  broke
the 8-bit printf format macros (PRI*8), for scenarios when newlib is
configured either with --enable-newlib-nano-formatted-io or without
--enable-newlib-io-c99-format is not used. Because the new code
defines these macros to the "hh" formats, which are not supported
Is it actually a problem that PRI* macros don't work without support for C99?
After all, these are used for C99 types, so not really needed without C99...
Further discussion is most welcome!