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).

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)

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)'
F

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

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))
OR
sprintf ("%02X\n", round (255 * color))

NOT
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?

Subtype

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.

b

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'.

t

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.

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

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.