[R-SIG-Mac] Unexpected behavior from sprintf()

[Simon Urbanek]

On Apr 24, 2012, at 9:12 PM, Duncan Murdoch wrote:

> On 12-04-24 5:12 PM, Simon Urbanek wrote:
>> 
>> On Apr 24, 2012, at 4:24 PM, Joran Elias wrote:
>> 
>>> I stumbled across this by accident from this StackOverflow question:
>>> 
>>> http://stackoverflow.com/q/10300325/324364
>>> 
>>> and a subsequent discussion in the StackOverflow R chat room:
>>> 
>>> http://chat.stackoverflow.com/transcript/message/3431991#3431991
>>> 
>>> The issue is the output from the following code:
>>> 
>>> sprintf('%05s',as.character(1:5))
>>> 
>>> It appears that when this is run in OS X in either 2.14.2 or 2.15.0, the
>>> output is:
>>> 
>>> [1] "00001" "00002" "00003" "00004" "00005"
>>> 
>>> whereas when it is run on other platforms (I saw examples from various
>>> Windows versions and one user on Ubuntu, all using 2.15.0 I believe) you
>>> get:
>>> 
>>> [1] "    1" "    2" "    3" "    4" "    5"
>>> 
>>> There was some uncertainty as to which behavior is "expected".
>> 
>> The behavior of "%0s" is undefined -- this is documented both by R and POSIX (arguably more clearly in the latter), so any behavior should be expected.
>> 
>> 
>>> Does anyone
>>> have any insight into which behavior is "correct" and whether this is a bug
>>> or not?
>>> 
>> 
>> It is not a bug. The formatting is done by the OS, so the results are always OS-dependent -- since %0s is undefined, the OS can choose to interpret it any way it wants.
> 
> Here's a slightly related question:  If a single percent sign appears in a string, not as the start of a conversion spec, is the behaviour defined?  For example, something taken from the R do_sprintf source in one of the error messages:
> 
> "the '%*' constructed 'fmt2' exceeds maximum of %d"
> 
> There's certainly one decimal value to be displayed at the end, but is the %* guaranteed to be interpreted literally?  The R sprintf parser gets confused by this one, but it's actually in the C code; is it a legal C format string?
> 

Again, POSIX says the behavior is undefined in that case:

"If a conversion specification does not match one of the above forms, the behavior is undefined. If any argument is not the correct type for the corresponding conversion specification, the behavior is undefined."

The only reliable way to emit a percent sign is "%%". The example above is certainly a bug.

Cheers,
Simon