[R-SIG-Mac] Unexpected behavior from sprintf()
Prof Brian Ripley
ripley at stats.ox.ac.uk
Wed Apr 25 07:49:54 CEST 2012
On 25/04/2012 03:33, Simon Urbanek wrote:
>
> 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:
And to clarify, POSIX is aligned with C99 so in fact it is the C99
standard that is the authority here: section 7.13.6 to be precise.
The references on ?sprintf could do with updating.
>
> "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
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-SIG-Mac
mailing list