[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MinGW and 3 exponent digits

From: Michael Goffioul
Subject: Re: MinGW and 3 exponent digits
Date: Tue, 12 Nov 2013 17:45:12 -0500

On Tue, Nov 12, 2013 at 3:57 PM, Rik <address@hidden> wrote:
On 11/12/2013 12:33 PM, John W. Eaton wrote:
> On 11/12/2013 03:18 PM, Rik wrote:
>> 11/12/13
>> All,
>> Apparently MinGW provides a work-around for the non-standard Windows
>> behavior of printing 3 exponent digits through the environment variable
>> PRINTF_EXPONENT_DIGITS.  If this variable is set to 2 then only two digits
>> will be displayed.
>> Sample code:
>> octave-cli:1> format short e
>> octave-cli:2> pi
>> ans =   3.1416e+000
>> octave-cli:3> setenv ("PRINTF_EXPONENT_DIGITS", "2")
>> octave-cli:4> pi
>> ans =    3.1416e+00
>> Should we look to put something in Octave's start-up code which sets this
>> environment variable when MinGW is detected?
> What does it do when this environment variable is set?
Exactly, I don't know.  This announcement on the MinGW mailing list
(http://marc.info/?l=mingw-notify&m=121692138826851) seems to suggest that
they inserted a printf shim layer between user's code and MSVCRT.  It seems
to suggest that it calls _set_output_format when it is possible to do so,
otherwise it takes care of the printing issues itself.
> Is it not possible to call _set_output_format if we are compiling with
> MinGW?
Yes, if the windows systems has MSVCR80.DLL and MinGW can take advantage of
it.  Brief reports suggest that this is sometimes difficult for MinGW.  But
it would also make us dependent on the particulars of the Windows system.
If the user doesn't have this dll then they are out of luck, whereas MinGW
will always be around by definition.

This post seems to suggest that the particular way PRINTF_EXPONENT_DIGITS
got implemented can be slow
But this might have been fixed by now.

The report above suggests that the slow down is due to calling getenv for every call to *printf function. The function getenv is coming from the the MSVC runtime DLL. I don't know if it's fixable at all, as it's out of the control of MinGW.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]