Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different behavior of %g format under Windows #6579

Closed
vicuna opened this issue Sep 25, 2014 · 4 comments
Closed

Different behavior of %g format under Windows #6579

vicuna opened this issue Sep 25, 2014 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Sep 25, 2014

Original bug ID: 6579
Reporter: @alainfrisch
Status: acknowledged (set by @damiendoligez on 2014-12-17T22:14:14Z)
Resolution: open
Priority: low
Severity: tweak
Category: platform support (windows, cross-compilation, etc)
Tags: junior_job
Monitored by: @gasche @hcarty

Bug description

By default, Windows uses three digits for the exponent in scientific notation, while two digits are usually used on other systems. This can give different result and break some non-regression tests that compare textual outputs. I know there could be other sources of textual differences between Windows and Unix around display of floating point values, but this one seems to be easily fixable using _set_output_format :

http://msdn.microsoft.com/en-us/library/0fatw238%28v=vs.80%29.aspx

Is it a good idea to do that automatically upon startup of the OCaml runtime under Windows?

@vicuna
Copy link
Author

vicuna commented Sep 25, 2014

Comment author: @gasche

I think that's a reasonable idea indeed.

@vicuna
Copy link
Author

vicuna commented Dec 17, 2014

Comment author: @damiendoligez

Just a remark, this is a rare case where Windows gets it right and Unix gets it wrong: Unix adds some useless digits, but not enough to guarantee a fixed width.

I'm on the fence.

@jflopezfernandez
Copy link
Contributor

Is this issue still active? I noticed it's from 2014.

I did some research and the _set_output_format function has actually been deprecated, but as I was looking through the codebase I saw the printf.ml and printf.mli files, where they emulate the C library's own printf function, so maybe we could simply explicitly state the required padding with something like %0.2f or something like that? I'd have to see the tests that are failing, though, so I'm not sure if it's as quick a fix as that.

@github-actions
Copy link

github-actions bot commented Jun 5, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Jun 5, 2020
@github-actions github-actions bot closed this as completed Jul 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants