bugGNU Octave - Bugs: bug #44245, need configurable warning when...


bug #44245: need configurable warning when sprintf format contains integer code, but value is real number

Submitter:  Rik <rik5>
Submitted:  Fri 13 Feb 2015 11:18:34 PM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Confirmed Assigned to:  jwe
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Mon 02 Mar 2015 08:36:29 PM UTC, comment #10: 

Re-titling for the remaining issue.  Dropping severity to normal since this will no longer gate the 4.0 release.

Rik <rik5>
Project Administrator
Tue 17 Feb 2015 12:54:34 AM UTC, comment #9: 

I checked in a cset where I attempted to find all uses of printf with integer format codes and ensure that the inputs were, in fact, integers (http://hg.savannah.gnu.org/hgweb/octave/rev/5f2c0ca0ef51).

Rik <rik5>
Project Administrator
Mon 16 Feb 2015 10:57:01 PM UTC, comment #8: 

I think Matlab uses '%e' instead of '%g'. Maybe we should just do that too.

John W. Eaton <jwe>
Project Administrator
Mon 16 Feb 2015 09:41:10 PM UTC, comment #7: 

Oh bother Matlab!

> We could have a warning about these formats when converting non-integer values. I suppose it should be disabled by the --traditional option.

If you can do that I think that is the best way to support this.  It's unclear how much code relies on the current Octave implementation, but at least the warning would flush it out.

I will take a look at the 1367 instances of printf in core and fix them.

What does Matlab do with the string format specification and a double value?  Does it also print out using '%g'?

sprintf ('%s\n', 15.2)

Rik <rik5>
Project Administrator
Mon 16 Feb 2015 05:44:16 PM UTC, comment #6: 

Yes, it is different.

Also, a format like '%bX' appears to say take the value, convert it to double, and print the hex representation of the bits.  So that is not what you are expecting for the 15.2 value.  Instead it is some 16-character hex string that represents the bytes corresponding to the double precision floating point value.

We could have a warning about these formats when converting non-integer values.  I suppose it should be disabled by the --traditional option.

John W. Eaton <jwe>
Project Administrator
Mon 16 Feb 2015 05:27:42 PM UTC, comment #5: 

Has Matlab really chosen to diverge from all other scripting languages?

I first tried in C to figure out what the base library call does

double x = 15.2
printf ("%0X\n", x);

When compiling:
sprintftst.c:11:3: warning: format ‘%X’ expects argument of type ‘unsigned int’, but argument 2 has type ‘double’ [-Wformat]

Run-time value
=> 3180F000

Okay, so that makes sense.  In C the format code determines how a block of memory will be interpreted.

In scripting languages, however, the value is polymorphic and the format code is a suggestion on how the output should be formatted, not what the underlying value truly is.  If I ask for an integer display format, I expect to see whatever underlying value there is, formatted as an integer.

I checked in Perl and Python and this is indeed what happens.

perl -e 'printf ("%0X\n", 15.2)'

python -c 'print "%0X" % (15.2)'

If Matlab is really doing this then do they also have a warning, like C, that gets printed when you feed incorrect arguments to a format code?  That would seem not only reasonable, but mandatory.  In effect, they are requiring a verbose coding style where the programmer casts their inputs to the required type ahead of printing rather than just using the programmer's intention as specified in the printf format code.  This goes against the DRY (Don't Repeat Yourself) principle of programming.  In the gnuplot example that uncovered this you would have to write

sprintf ("%02X\n", uint8 (255 * color))
sprintf ("%02X\n", round (255 * color))

sprintf ("%02X\n", 255 * color)

If we must follow Matlab, then we need to make the warning in the NEWS file much more explicit and list alternatives for transitioning existing Octave code.  We would also need to validate the Octave core code.  I just did a grep for printf in the scripts directory and there are 1367 instances.  A lot of these don't use integer format conversions, but we would need to check any ones that do and figure out a workaround (probably floor() to match earlier behavior).

Should we also be introducing the non-standard subtype fields from Matlab?


The subtype field is a single alphabetic character that immediately precedes the conversion character. The following nonstandard subtype specifiers are supported for the conversion characters %o, %x, %X, and %u.


The underlying C data type is a double rather than an unsigned integer. For example, to print a double-precision value in hexadecimal, use a format like '%bx'.


The underlying C data type is a float rather than an unsigned integer.

It seems that the correct code for Matlab would then be '%bX' rather than '%X' to get existing Octave behavior.  See http://www.mathworks.com/help/matlab/matlab_prog/formatting-strings.html.

Rik <rik5>
Project Administrator
Sun 15 Feb 2015 11:05:01 PM UTC, comment #4: 

I'm not sure that this is a bug.  I think the change was made for Matlab compatibility, though it appears that Matlab uses a short e format, even for small values like 15.2.  If there is a bug, I think it is not having a test for it and an explicit comment about the compatibility issue.

John W. Eaton <jwe>
Project Administrator
Fri 13 Feb 2015 11:41:43 PM UTC, comment #3: 

It wasn't quite as certain that the other bug, #42235, was as serious and therefore of Severity Blocker.

Rik <rik5>
Project Administrator
Fri 13 Feb 2015 11:26:25 PM UTC, comment #2: 

Should both bugs be blockers?  They are both regressions, right?  Both are likely unintended consequences of changes I made, so I'll try to take a look at them.  I claimed the other bug as well.

John W. Eaton <jwe>
Project Administrator
Fri 13 Feb 2015 11:20:12 PM UTC, comment #1: 

See also bug #42235 which is also related to changes made to the printf family of functions and could possibly be fixed at the same time as this bug.

Rik <rik5>
Project Administrator
Fri 13 Feb 2015 11:18:34 PM UTC, original submission:  

Real number input to sprintf, and presumably the other printf family of functions, is passing through floating point numbers without modification.

In version 3.8.2 the sample code correctly prints 'F'.  This was first discovered in a gnuplot bug report and it may be causing multiple problems in the code base.

This is a blocker for the 4.0 release.

Rik <rik5>
Project Administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-02 rik5 Severity5 - Blocker 3 - Normal
        Summarysprintf ("%0X", 15.2) prints floating point number 15.2 rather than \'F\' need configurable warning when sprintf format contains integer code, but value is real number

    Back to the top

    Powered by Savane 3.9