Revert change to %t default precision
#22796
Conversation
Signed-off-by: Jeremiah Corrado <[email protected]>
Signed-off-by: Jeremiah Corrado <[email protected]>
Signed-off-by: Jeremiah Corrado <[email protected]>
| @@ -5013,7 +5013,7 @@ qioerr qio_conv_parse(c_string fmt, | |||
| } else if( specifier == 't' ) { | |||
| style_out->base = 10; | |||
| style_out->pad_char = ' '; | |||
| style_out->realfmt = 0; | |||
| style_out->realfmt = 2; | |||
There was a problem hiding this comment.
Just checking: should the same change be applied to %? -- in other words, was it decided that it should use a different precision from %t or was that accidental as well?
There was a problem hiding this comment.
My understanding was that %t setting style_out->realfmt=2 was a bug in the sense that it was a deviation from the default format. But now that it's deprecated, we should leave the bug in and use the %t -> %? transition as an avenue to move to the correct behavior.
In other words, with %?, I think we really want all of the following to be equivalent (as should have been the case for %t AFAIK):
writef("%?", myArrayOfReals);
write(myArrayOfReals);
stdout.withSerializer(DefaultSerializer).writef("%?", myArrayOfReals);
stdout.withSerializer(DefaultSerializer).write(myArrayOfReals);Does this agree with your understanding? (I'm also game to have a discussion about this with the IO subteam if you think there might be any doubt about what we should do here).
There was a problem hiding this comment.
Works for me. No real opinion from me on this point; I was just checking it was intentional, and it was.
The default floating point precision style for
%twas accidentally changed in #22766. This PR reverts that change.Also fixes .good files for compflags/TestWarnUnstableSuppression, which was failing on main.