[Mingw-notify] [ mingw-Patches-2016112 ] Make ALL *printf() functions deliver consistent output

[SourceForge.net <no...@so...>]

Patches item #2016112, was opened at 2008-07-11 09:59
Message generated for change (Comment added) made by aaronwl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2016112&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Keith Marshall (keithmarshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make ALL *printf() functions deliver consistent output

Initial Comment:
This submission supersedes or augments:
https://sourceforge.net/tracker/index.php?func=detail&aid=1983559&group_id=2435&atid=302435
https://sourceforge.net/tracker/index.php?func=detail&aid=1985560&group_id=2435&atid=302435

I've created an alternative implementation for the printf() format interpreter, to replace the current mingw_snprintf.c; this is accompanied by API wrappers for ALL of the *printf() functions, so delivering consistent output from the entire family, whether writing to streams or to process memory (strings).

I've attached both source, and a prebuilt library, libprintf.a, which may be linked ahead of libmingwex.a, to access this alternative implementation.

The source tarball includes a rudimentary test suite; please feel free to add additional test cases, and report any bugs you might uncover.

In writing this, I've attempted to maintain consistency with MSVCRT output, except where C99/POSIX mandate differently; I have also included, as does mingw_snprintf.c, support for BOTH the Microsoft and the C99/POSIX format conversion specifiers.  I've retained the Microsoft convention of at least three exponent digits in floating point conversions, but I've also provided an environment variable hook, such that users may set PRINTF_EXPONENT_DIGITS=2, if they prefer the C99/POSIX style; (I've also coded in support for _get_output_format(), if -D__MSVCRT_VERSION__=0x800, or greater, is added to the CFLAGS, when building this library code, and subsequently linking with a newer MSVCRT version).

At present, I have not prepared a final patch, for integration into libmingwex.a; before that can happen, agreement is required on the following:

As currently written, integration of these replacement functions into libmingwex.a will deny users access to the similarly named MSVCRT functions, for all but _snprintf() and _vsnprintf(), (for which the paradigm of mingw_snprintf.c will continue to apply).  Possibly, this isn't a great loss, since I've taken care to maintain close consistency with MSVCRT behaviour, except in the reporting of infinities and NaNs; however, no doubt there are some who will perceive this as a major issue.  To circumvent this, I can see two possible approaches:--

1) Do not integrate into libmingwex.a, but offer this as a free standing libprintf.a (say), which users could explicitly link to gain the new behaviour, or omit to retain the current status quo.

2) Provide an alternative mechanism for accessing the MSVCRT functions; (I am uncertain how to implement this, but Danny has suggested that it should be possible).

----------------------------------------------------------------------

>Comment By: Aaron W. LaFramboise (aaronwl)
Date: 2008-07-11 10:48

Message:
Logged In: YES 
user_id=1040098
Originator: NO

Regarding #2, I added the -p option to dlltool for this purpose.  I would
suggest something careful like __mingw_msvcrt_ as the aliased prefix.

An idea I've been thinking about lately (regarding some of my own
improvement) is high-level switches of some sort to switch between
different MinGW 'modes.'  The main motivation is the substantial
differences between people who want MinGW to be 1) a good minimalistic
subset of POSIX for porting 2) a good native Win32 compiler, or 3) a thin
wrapper around a Microsoft runtime.  Just as an observation, some important
MinGW users in the GCC community have expressed some alarm that MinGW is
drifting away from #3.

This can be done either with -D options or -m options; the latter are more
powerful, but harder to work with since we need to change GCC to work with
them.


----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2008-07-11 10:00

Message:
Logged In: YES 
user_id=823908
Originator: YES

File Added: pformat-0.0-lib.tar.gz

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2016112&group_id=2435