Works for me.  Marking as fixed and closing report.

Uh, nevermind that patch.  It doesn't really do the right thing.  I'll try to come up with a better solution.  Apparently  '%s' and '%c' conversions are supposed to do string conversions for any numeric value that is in the range of valid characters.  For Matlab, that seems to be any integer value between 0 and intmax ('uint16') regardless of the storage type (int, double, whatever)

I haven't looked through the relevant section in enough detail yet to wager any clarifications or guesses. But note that this bug is not limited to %c. It applies to all integer and floating point conversion formats when given a string argument, so all of the following should apparently be fixed: %c, %d, %i, %o, %u, %x, %X, %f, %e, %E, %g, and %G. All are working in 3.8 and not working on default. I've retitled to make sure that is not lost.

The following example in matlab shows that "%s" and "%c" are different:

>> sprintf ('%4c', 'abcd') % note the 3 white spaces before each character
ans =
   a   b   c   d
>> sprintf ('%4s', 'abcd')
ans =
abcd
>> sprintf ('%c,%c,%c,%c', 'abcd')
ans =
a,b,c,d
>> sprintf ('%s,%s,%s,%s', 'abcd')
ans =
abcd,

The string 'abcd' is an array of characters. In Mike's test, all the characters are treated one after the other using the same format specifier. This behavior is true for all format specifiers except %s which is meant to handle multiple characters at the same time [1].

[1] http://www.mathworks.fr/fr/help/matlab/ref/sscanf.html

On a pretty old Matlab version (r2008b):

>> s = sprintf('%c', 'abcd')
s = abcd
>> s = sprintf('%d', 'abcd')
s = 979899100
>> s = sprintf('%f', 'abcd')
s = 97.00000098.00000099.000000100.000000

I've just recompiled a fresh version of the dev branch and I now get errors each time a %s type is used in a format specification:

octave> fprintf('%c','T')
error: invalid conversion from string to real scalar
error: octave_base_value::int64_scalar_value(): wrong type argument 'sq_string'