Error in "%e" formatting.

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Error in "%e" formatting.

sisyphus1
Hi,

On linux and cygwin, printf("%e", -1.25) outputs 1.250000+00.
On windows it outputs 1.250000+000. (There's an extra '0' at the end).
Compiling on windows with the '-ansi' switch makes no difference.

Because of this error in the windows runtime, 3 tests in the mpfr-2.4.0-rc1
test suite fail.

Can this aspect of the "%e" formatting be fixed in a future release of MinGW
?

Cheers,
Rob


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

Gisle Vanem
"Sisyphus" <[hidden email]> wrote:

> Can this aspect of the "%e" formatting be fixed in a future release of MinGW

How about you fix it yourself? If at all it should be
fixed. Who says linux and cygwin is correct in this respect.

--gv

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

sisyphus1

----- Original Message -----
From: "Gisle Vanem" <[hidden email]>
To: "MinGW Users List" <[hidden email]>
Sent: Wednesday, December 17, 2008 6:26 PM
Subject: Re: [Mingw-users] Error in "%e" formatting.


> "Sisyphus" <[hidden email]> wrote:
>
>> Can this aspect of the "%e" formatting be fixed in a future release of
>> MinGW
>
> How about you fix it yourself? If at all it should be
> fixed. Who says linux and cygwin is correct in this respect.
>

The mpfr developers are of the view that linux and cygwin is correct - and
that windows is failing to comply with ansi standards. Those guys are
usually pretty switched on when it comes to ansi standards. Are they wrong
on this occasion ? If so, I'm certainly willing to take them to task over
the matter.

Cheers,
Rob


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

Greg Chicares
In reply to this post by Gisle Vanem
On 2008-12-17 07:26Z, Gisle Vanem wrote:
> "Sisyphus" <[hidden email]> wrote:
>
>> Can this aspect of the "%e" formatting be fixed in a future release of MinGW
>
> How about you fix it yourself? If at all it should be
> fixed. Who says linux and cygwin is correct in this respect.

The OP had earlier said:

| On linux and cygwin, printf("%e", -1.25) outputs 1.250000+00.
| On windows it outputs 1.250000+000. (There's an extra '0' at the end).

and here's the relevant part of C99 7.19.6.1/8:

| The exponent always contains at least two digits, and only
| as many more digits as necessary to represent the exponent.

It's been discussed here before:

http://search.gmane.org/?query=7.19.6.1%2F8+mingw

in the context of snprintf(), for which Keith wrote a complete
and painstaking replacement in libmingwex.


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

Earnie Boyd
In reply to this post by Gisle Vanem

Quoting Gisle Vanem <[hidden email]>:

> Who says linux and cygwin is correct in this respect.
>

I would imagine that if Linux ansi wasn't correct, it would be fixed by
now.  There are numerous FOSS programmers that would take the issue to
bat.  As for MinGW, it would require an extension added to the -ansi
work already at task.  Patches to mingwex would graciously be accepted.
  Patches must be original work with a license of public domain.

Earnie

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

Keith Marshall
In reply to this post by sisyphus1
On Wednesday 17 December 2008 02:50:42 Sisyphus wrote:
> On linux and cygwin, printf("%e", -1.25) outputs 1.250000+00.
> On windows it outputs 1.250000+000. (There's an extra '0' at the
> end).

That's correct.  ISO C99 and POSIX both require *a* *minimum* of two
exponent digits.  Linux and Cygwin aim to conform to POSIX, hence two
digits is what they use.  OTOH, MinGW strives for conformance with
the MS-Windows standards, as documented on MSDN; these stipulate a
minimum of *three* exponent digits.

> Compiling on windows with the '-ansi' switch makes no difference.

Well no, it doesn't, because providing three digits, as required by
the MSW standard, doesn't violate the ISO C99 requirement of no less
than two; (three is not less than two).  Of course, it isn't entirely
compliant with the ISO C99 stipulation that, subject to there being
at least two digits, there shall be no more than are necessary to
represent the required exponent value.  However, we comply with the
MSDN standard, requiring at least three digits, because that is what
is most applicable on our host platform of (maybe reluctant) choice,
and is therefore best aligned with our minimalist objective, which is
to provide a free compiler suite for the *native* MSW platform.

> Because of this error in the windows runtime, 3 tests in the
> mpfr-2.4.0-rc1 test suite fail.

It *isn't* an error in the MSW runtime; MPFR should be cognisant of
the standards which prevail, on the host platform for which it is
being deployed -- those three tests should be rewritten, to accept
whatever minimum number of exponent digits is standard for the host.

> Can this aspect of the "%e" formatting be fixed in a future release
> of MinGW ?

It isn't broken, so there is nothing for us to fix.  In a follow up
post, Gisle Vanem said:
> How about you fix it yourself?  If at all it should be fixed.

See above; there is nothing to fix.  However, if you link with MSVCR80
or later, *you* can call Microsoft's _set_output_format() function,
to select _TWO_DIGIT_EXPONENT mode for subsequent printf() formatted
output; if you use mingwrt-3.15 or later, you can add

  PRINTF_EXPONENT_DIGITS=2

to your (exported) environment, and compile with `-ansi' or `-posix',
to achieve the same effect, with *any* MinGW supported version of
MSVCRT.  (An RTFM is probably warranted here; see the release notes
for mingwrt-3.15, at http://tinyurl.com/6h6bbc).

GV went on to ask:
> Who says linux and cygwin is correct in this respect?

To which Rob [Sisyphus] replied:
> The mpfr developers are of the view that linux and cygwin is
> correct - and that windows is failing to comply with ansi standards.

So what?  Since when have Gates, Ballmer and cohorts ever complied
with *any* recognised standards but their own?  For better, or for
worse, ANSI is largely irrelevant on MS-Windows; the only "standard"
which is applicable is what is documented on MSDN.

> Those guys are usually pretty switched on when it comes to ansi
> standards.

And indeed, when talking about a POSIX or ANSI compliant host, they
are correct on this point.  However, in the case of *native* MSW...

> Are they wrong on this occasion ?

With all due respect to the MPFR developers, yes, they are dead wrong
on this occasion; when targetting an MSW host, neither ANSI nor POSIX
necessarily applies, and if they insist that those standards must be
honoured, then I fear that they may have completely lost the plot.

> If so, I'm certainly willing to take them to task over the matter.

Please do.

--

Regards,
Keith.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

Keith Marshall
In reply to this post by Earnie Boyd
On Wednesday 17 December 2008 13:16:51 Earnie Boyd wrote:
> Quoting Gisle Vanem:
> > Who says linux and cygwin is correct in this respect.
>
> I would imagine that if Linux ansi wasn't correct, it would be
> fixed by now.  There are numerous FOSS programmers that would take
> the issue to bat.

Linux and Cygwin are both correct; since both claim to be POSIX
systems, they must do as POSIX demands, and that is exactly what they
do.

> As for MinGW,

It too is correct; it doesn't claim POSIX compliance, and the criteria
for determination of "correctness" are different.

> it would require an extension  added to the -ansi work already at
> task.

The necessary infrastructure is already in place, but it needs a bit
of user intervention, to get the strict ANSI/POSIX behaviour:

  #include <stdio.h>
  #include <stdlib.h>

  int main()
  {
    _putenv( "PRINTF_EXPONENT_DIGITS=2" );
    printf( "Value of 1.25, formatted using \"%%e\", is %e\n", 1.25 );
    return 0;
  }

will emit two digit exponents, when compiled with `-ansi' or `-posix',
and mingwrt-3.15 or later.

> Patches to mingwex would graciously be accepted. Patches must be
> original work with a license of public domain.

We could consider a start-up hook, in crt1.o, and triggered by
conditional `startfiles' logic in the GCC specs file, to make that
`_putenv()' assignment, if there is sufficient demand to support two
digit exponents by default, for the `-ansi' and `-posix' cases; (but
*not* for any of the #define methods of invoking MinGW's ANSI style
output formatting capabilities).

--

Regards,
Keith.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

sisyphus1

----- Original Message -----
From: "Keith Marshall" <[hidden email]>
[snip]

>
> The necessary infrastructure is already in place, but it needs a bit
> of user intervention, to get the strict ANSI/POSIX behaviour:
>
>  #include <stdio.h>
>  #include <stdlib.h>
>
>  int main()
>  {
>    _putenv( "PRINTF_EXPONENT_DIGITS=2" );
>    printf( "Value of 1.25, formatted using \"%%e\", is %e\n", 1.25 );
>    return 0;
>  }
>
> will emit two digit exponents, when compiled with `-ansi' or `-posix',
> and mingwrt-3.15 or later.

Aaah ... this is excellent. Thanks !!

In the msys shell I did 'export PRINTF_EXPONENT_DIGITS=2', then re-built gmp
and mpfr (with the -ansi switch) and the problem with "%e" is solved.

Now I find that there's (at least) one more printf formatting issue in the
mpfr-2.4.0-rc1 test suite, which I'll have to take a look at when I have the
time - hopefully tomorrow night. (I'll also be sure to check out
http://tinyurl.com/6h6bbc while doing that.)

[snip]

> We could consider a start-up hook, in crt1.o, and triggered by
> conditional `startfiles' logic in the GCC specs file, to make that
> `_putenv()' assignment, if there is sufficient demand to support two
> digit exponents by default, for the `-ansi' and `-posix' cases; (but
> *not* for any of the #define methods of invoking MinGW's ANSI style
> output formatting capabilities).
>

That would certainly have my support.

If "two digit exponents" is the ansi standard, then I think it a little
surprising that a switch named "-ansi" doesn't already have "two digit
exponents" by default. (Admittedly, there may well be issues here, with
which I am not acquainted.)

Thanks for the feedback, guys - and the excellent work.

Cheers,
Rob


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

Keith Marshall
On Thursday 18 December 2008 09:23:48 Sisyphus wrote:
> > We could consider a start-up hook, in crt1.o, and triggered by
> > conditional `startfiles' logic in the GCC specs file, to make
> > that `_putenv()' assignment, if there is sufficient demand to
> > support two digit exponents by default, for the `-ansi' and
> > `-posix' cases; (but *not* for any of the #define methods of
> > invoking MinGW's ANSI style output formatting capabilities).
>
> That would certainly have my support.

It makes sense to me too, although with further consideration, I think
that maybe this proposal goes just a bit too far.

> If "two digit exponents" is the ansi standard, then I think it a
> little surprising that a switch named "-ansi" doesn't already have
> "two digit exponents" by default.

POSIX says only, (and explicitly, no more than):
http://www.opengroup.org/onlinepubs/009695399/functions/fprintf.html
| The exponent shall contain at least two digits.

If this were the end of the story, then two or three digits wouldn't
matter; either would conform to the POSIX standard.  However, POSIX
also says:
| The functionality described on this reference page is aligned with
| the ISO C standard. Any conflict between the requirements described
| here and the ISO C standard is unintentional. This volume of IEEE
| Std 1003.1-2001 defers to the ISO C standard.

and since the ISO C standard says, in section 7.19.6.1/8:
| The exponent always contains at least two digits, and only
| as many more digits as necessary to represent the exponent.

then three digits is an explicit violation of the second part of that
clause, and therefore also an *implicit* violation of POSIX.

> (Admittedly, there may well be issues here, with which I am not
> acquainted.)

Yes, there are several issues:

* There is a significant groundswell of opinion that MinGW should
  not conform to POSIX, nor to ISO C, when to do so is distinctly
  different from the behaviour of MSVC, (which defines the norm
  for applications on native MS-Windows).  IIRC, and in spite of
  significant differences between GCC and MSVC, this opinion is
  even held by some high profile individuals within the GCC
  development community, (although IMO, that counts for little,
  when those individuals choose not to make their opinions known
  to *this*, the MinGW community, via *this* mailing list).

* Prior to mingwrt-3.15, we had snprintf() and vsnprintf() providing
  output with two digit exponents, while all other functions in the
  printf() family used three.  That inconsistency was undesirable, and
  was highlighted in more than one bug report.

* Since three exponent digits is the norm on MS-Windows, I chose to
  standardise the implementation for mingwrt-3.15, with this default.  
  To do otherwise would lead to inconsistency, even within any single
  application, if some of its objects are compiled with printf() and
  friends mapped to __mingw_printf() equivalents, while other objects
  may still refer to __msvcrt_printf() equivalents.

* The standard behaviour of `-ansi' and `-posix' affect only the
  *compile* time state of the affected translation units.  That
  doesn't help to achieve the desired effect, which must be
  determined from a condition prevailing at *run* time.  The
  `startfiles' hook I am proposing will subvert that standard
  behaviour, to pre-empt a run time condition; as such it may be
  considered somewhat kludgy; it would definitely introduce a
  non-standard side effect for `-ansi' and for `-posix', extending
  their effects to *link* time, (and as such, the effect would only
  be apparent if these switches are specified when linking the
  executable).  Non-standard, therefore maybe less than desirable.

* Implementation of this mechanism, as I've proposed it, will
  require not only some ground work in mingwrt itself, but also
  some supporting modifications in the GCC specs file.  In the
  long term, that implies a need for co-operation from the GCC
  maintainers, to accommodate the necessary changes within the
  built-in specs.  For currently released MinGW-GCC, it requires
  *users* to retrofit the necessary changes into their existing
  specs files, (or to discard any local customisations, install
  an update package, and then reimplement any customisations
  they wish to preserve).

Perhaps all of the above makes the idea less attractive?  There is a
simpler alternative, which I've already described; it shifts the onus
on to application maintainers to add the:

  _putenv( "PRINTF_EXPONENT_DIGITS=2" );

early in their main() functions, (possibly, or even preferably guarded
by `#if defined __MINGW32__').  With that in place, any printf() call
which is mapped to __mingw_printf(), (however that is achieved), will
emit output with two digit exponents.  IMO, this represents the most
effective, and most robust solution, (and not just because it doesn't
entail additional work for me).

In any of my own applications, I'd probably implement it like this[*]:

  int main()
  {
  # ifdef __MINGW32__
    if( _getenv( "PRINTF_EXPONENT_DIGITS" ) == NULL )
      _putenv( "PRINTF_EXPONENT_DIGITS=2" );
  # endif

    :
    :

so that end users have the option to override the default behaviour,
if they so wish.

Or, what about this "half-way house" implementation?  If I were to put
something like:

  if( (__mingw32_CRTprintf_exponent_style != NULL)
  &&  (_getenv( "PRINTF_EXPONENT_DIGITS" ) != NULL)  )
    _putenv( __mingw32_CRTprintf_exponent_style );

into the MinGW start-up file, with a default:

  char *__mingw32_CRTprintf_exponent_style = NULL;

in libmingw32.a; the application could then add an explicit global
initialisation[*] for:

  # ifdef __MINGW32__
    char *__mingw32_CRTprintf_exponent_style
         = "PRINTF_EXPONENT_DIGITS=2";
  #endif

to achieve the same effect, in a perhaps tidier manner?

[*] Ideally, with appropriate MINGW32_VERSION checks added.

> Thanks for the feedback, guys - and the excellent work.

You're welcome.

--

Regards,
Keith.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

sisyphus1

----- Original Message -----
From: "Keith Marshall" <[hidden email]>

[snip]

>> (Admittedly, there may well be issues here, with which I am not
>> acquainted.)
>
> Yes, there are several issues:
>
> * There is a significant groundswell of opinion that MinGW should
> not conform to POSIX, nor to ISO C, when to do so is distinctly
> different from the behaviour of MSVC, (which defines the norm
> for applications on native MS-Windows). IIRC, and in spite of
> significant differences between GCC and MSVC, this opinion is
> even held by some high profile individuals within the GCC
> development community, (although IMO, that counts for little,
> when those individuals choose not to make their opinions known
>  to *this*, the MinGW community, via *this* mailing list).
>
> * Prior to mingwrt-3.15, we had snprintf() and vsnprintf() providing
> output with two digit exponents, while all other functions in the
> printf() family used three. That inconsistency was undesirable, and
> was highlighted in more than one bug report.
>
> * Since three exponent digits is the norm on MS-Windows, I chose to
> standardise the implementation for mingwrt-3.15, with this default.
> To do otherwise would lead to inconsistency, even within any single
> application, if some of its objects are compiled with printf() and
> friends mapped to __mingw_printf() equivalents, while other objects
> may still refer to __msvcrt_printf() equivalents.
>
> * The standard behaviour of `-ansi' and `-posix' affect only the
> *compile* time state of the affected translation units. That
> doesn't help to achieve the desired effect, which must be
> determined from a condition prevailing at *run* time. The
> `startfiles' hook I am proposing will subvert that standard
> behaviour, to pre-empt a run time condition; as such it may be
> considered somewhat kludgy; it would definitely introduce a
> non-standard side effect for `-ansi' and for `-posix', extending
> their effects to *link* time, (and as such, the effect would only
> be apparent if these switches are specified when linking the
> executable). Non-standard, therefore maybe less than desirable.
>
> * Implementation of this mechanism, as I've proposed it, will
> require not only some ground work in mingwrt itself, but also
> some supporting modifications in the GCC specs file. In the
> long term, that implies a need for co-operation from the GCC
> maintainers, to accommodate the necessary changes within the
> built-in specs. For currently released MinGW-GCC, it requires
> *users* to retrofit the necessary changes into their existing
> specs files, (or to discard any local customisations, install
> an update package, and then reimplement any customisations
> they wish to preserve).

The first of the above points is not all that compelling, imo.
It's not as if anybody's breaking the existing MSVC-compilance that already
exists, and no-one is being forced to compile with -ansi.
But to provide an option to those who would like their printf's to be more
ansi-compliant is a big plus for mingw.

The other points (above) do, however, carry significant weight.

For mine, there's nothing drastically wrong with the current state of
affairs. I just set the environment variable, compile with -ansi, and
everything goes fine. You could go to the trouble you've outlined above, and
that just means that the environment variable doesn't have to be set ....
all of that trouble hardly seems warranted. (My suggestion of including
PRINTF_EXPONENT_DIGITS=2 as the default for the -ansi switch was based on
the false assumption that it could be done with very little effort.)

I've already set the environment variable PRINTF_EXPONENT_DIGITS=2. I guess
I can always override it in an app with a _putenv call, if I ever needed to
.... but it's hard to imagine that, outside of testing, I would ever want to
use the -ansi switch *without* PRINTF_EXPONENT_DIGITS=2.

[snip]

> Or, what about this "half-way house" implementation?  If I were to put
> something like:
>
> if( (__mingw32_CRTprintf_exponent_style != NULL)
> && (_getenv( "PRINTF_EXPONENT_DIGITS" ) != NULL) )
> _putenv( __mingw32_CRTprintf_exponent_style );
>
> into the MinGW start-up file, with a default:
>
> char *__mingw32_CRTprintf_exponent_style = NULL;
>
> in libmingw32.a; the application could then add an explicit global
> initialisation[*] for:
>
> # ifdef __MINGW32__
> char *__mingw32_CRTprintf_exponent_style
> = "PRINTF_EXPONENT_DIGITS=2";
> #endif
>
> to achieve the same effect, in a perhaps tidier manner?
>

Not sure .... as long as we're still able to compile other people's source
code with PRINTF_EXPONENT_DIGITS=2 (and without having to modify that source
code).

In view of what you've told me, I think it's fair enough that things stay as
they are.

Cheers,
Rob


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.
Reply | Threaded
Open this post in threaded view
|

Re: Error in "%e" formatting.

sisyphus1
In reply to this post by Keith Marshall

----- Original Message -----
From: "Keith Marshall" <[hidden email]>

[snip]

>> Are they wrong on this occasion ?
>
> With all due respect to the MPFR developers, yes, they are dead wrong
> on this occasion; when targetting an MSW host, neither ANSI nor POSIX
> necessarily applies, and if they insist that those standards must be
> honoured, then I fear that they may have completely lost the plot.
>
>> If so, I'm certainly willing to take them to task over the matter.
>
> Please do.
>

I'm informed that the upcoming mpfr-2.4.0-rc2 test suite will compare its
test results against hard coded values, rather than against values that the
system produces. This should mean that all of the printf() formatting issues
I've enquired about over the last week or so, will no longer have any
bearing wrt mpfr test suite.

For mine, it has been a "blessing in disguise" that they designed the rc1
test suite the way they did. I've learned some things as a result, and a
couple of small MinGW bugs were uncovered in the process.

Cheers,
Rob


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.