Bug in sprintf?

W

Wes Gamble

All,

Why does this fail?

irb(main):009:0> sprintf("%d", '08')
ArgumentError: invalid value for Integer: "08"
from (irb):9:in `sprintf'
from (irb):9

I assume it's because the 08 is being as an octal number prior to being
changed to a decimal. 01 - 07 work fine, 09 breaks.

But I'm telling sprintf to interpret it as decimal, so why can't I have
leading zeroes?

Please explain to me how this is expected behavior.

Thanks,
Wes
 
W

William Crawford

Wes said:
I assume it's because the 08 is being as an octal number prior to being
changed to a decimal. 01 - 07 work fine, 09 breaks.

Because 8 isn't an octal number. 0-7 are octal.
 
A

ara.t.howard

All,

Why does this fail?

irb(main):009:0> sprintf("%d", '08')
ArgumentError: invalid value for Integer: "08"
from (irb):9:in `sprintf'
from (irb):9

I assume it's because the 08 is being as an octal number prior to being
changed to a decimal. 01 - 07 work fine, 09 breaks.

But I'm telling sprintf to interpret it as decimal, so why can't I have
leading zeroes?

Please explain to me how this is expected behavior.

Thanks,
Wes

because:

harp:~ > cat a.c
main(){ char s[42]; int r = sprintf (s, "%d", 07); printf ("%d: <%s>\n", r, s); }


harp:~ > gcc a.c
harp:~ > a.out
1: <7>


harp:~ > cat a.c
main(){ char s[42]; int r = sprintf (s, "%d", 08); printf ("%d: <%s>\n", r, s); }


harp:~ > gcc a.c
a.c: In function `main':
a.c:1: numeric constant contains digits beyond the radix


ruby uses 'Integer(s)' to convert strings to ints and


harp:~ > ri Kernel.Integer
--------------------------------------------------------- Kernel#Integer
Integer(arg) => integer
------------------------------------------------------------------------
Converts _arg_ to a +Fixnum+ or +Bignum+. Numeric types are
converted directly (with floating point numbers being truncated).
If _arg_ is a +String+, leading radix indicators (+0+, +0b+, and
+0x+) are honored. Others are converted using +to_int+ and +to_i+.
This behavior is different from that of +String#to_i+.

Integer(123.999) #=> 123
Integer("0x1a") #=> 26
Integer(Time.new) #=> 1049896590


harp:~ > ruby -e' Integer "07" '

harp:~ > ruby -e' Integer "08" '
-e:1:in `Integer': invalid value for Integer: "08" (ArgumentError)
from -e:1

so it's expected, documented, and consistent with c.

a good pattern to use is:


harp:~ > ruby -e' atoi = lambda{|s| Integer(s) rescue %r/(\d+)/.match(s)[1].to_i rescue raise ArgumentError, s}; p(atoi["08"]); p(atoi["fubar"]) '
8
-e:1: fubar (ArgumentError)
from -e:1


because simply falling back on to_i yields


harp:~ > ruby -e' atoi = lambda{|s| Integer(s) rescue s.to_i}; p(atoi["08"]); p(atoi["fubar"]) '
8
0


regards.

-a
 
W

William Crawford

William said:
Because 8 isn't an octal number. 0-7 are octal.

-slaps self- Think before you reply, William.

On second thought, this -does- seem wrong. It doesn't matter if you
tell it to be decimal, octal or hex, it all comes up with an error on 08
and 09, and not 00 to 07.
 
C

Carlos

All,

Why does this fail?

irb(main):009:0> sprintf("%d", '08')
ArgumentError: invalid value for Integer: "08"
from (irb):9:in `sprintf'
from (irb):9 [...]
But I'm telling sprintf to interpret it as decimal, so why can't I have
leading zeroes?

Please explain to me how this is expected behavior.
[...]
[...]
ruby uses 'Integer(s)' to convert strings to ints and [...]
Kernel#Integer
[...]
If _arg_ is a +String+, leading radix indicators (+0+, +0b+, and
+0x+) are honored. [...]
so it's expected, documented, and consistent with c.

It is not expected, nor documented, because the documentation of sprintf
says:
d | Convert argument as a decimal number.

...which is very explicit in that the argument will be interpreted as a
decimal number, not octal.

Greetings.
 
W

Wes Gamble

Thanks for the comprehensive response.

Well, I can't really argue with the C implementation, of course...

BUT

it feels like if I declare my intent to interpret the sprintf input as a
_decimal_ number with %d (there's a %o if I wanted octal), that is
should allow for leading zeroes.

My intent in writing sprintf("%d", '08') is to say take the string 08
and turn it into the number 8.

It isn't to say here's an octal number, please convert it to decimal for
me. If I think the string is octal, I'll use %o for that.

So in the spirit of what the user expects, I still think this smells
bad.

Feel free to convince me otherwise.

Thanks again,
Wes
 
J

Jan Svitok

Thanks for the comprehensive response.

Well, I can't really argue with the C implementation, of course...

BUT

it feels like if I declare my intent to interpret the sprintf input as a
_decimal_ number with %d (there's a %o if I wanted octal), that is
should allow for leading zeroes.

My intent in writing sprintf("%d", '08') is to say take the string 08
and turn it into the number 8.

It isn't to say here's an octal number, please convert it to decimal for
me. If I think the string is octal, I'll use %o for that.

So in the spirit of what the user expects, I still think this smells
bad.

Feel free to convince me otherwise.

Thanks again,
Wes

As I see it, there are two separate things: WHAT number you want to
print, and HOW you want it print.

The latter one is specified by the format string.
The former one is specified by argument.

Think of sprintf("%d", 0x1234) or sprintf("%x", 123).

And it happens to be that '08' is in this case the same as 08 and that
is invalid octal number. QED. ;-)

Jano
 
M

Matthias Reitinger

Carlos said:
It is not expected, nor documented, because the documentation of sprintf
says:
d | Convert argument as a decimal number.

...which is very explicit in that the argument will be interpreted as a
decimal number, not octal.

I disagree on that. %d tells sprintf to expect an Integer as the
corresponding argument. Being given a String instead it tries to convert
it by calling Kernel#Integer. This fails for the reasons already
metioned.

Greetings, Matthias
 
D

Daniel Martin

Carlos said:
It is not expected, nor documented, because the documentation of
sprintf says:
d | Convert argument as a decimal number.

...which is very explicit in that the argument will be interpreted as
a decimal number, not octal.

I think that the problem here is that ruby is performing two
conversions, and the sprintf documentation only mentions one of them.

When you use '%d' in a sprintf(), ruby does a conversion of the
argument to an Integer using Kernel#Integer and then does the
conversion of the Integer to a portion of the output string as
documented.

Similarly, when you use %f in a sprintf(), ruby does a conversion of
the argument using Kernel#float and then does the conversion from
Float to part of the output string as documented.

So, we have:

sprintf("%d",'08') ==> ArgumentError
sprintf("%d",'8') ==> "8"
sprintf("%d",'08'.to_i) ==> "8"
sprintf("%f",'08') ==> "8.000000"

I think that if you're hitting this quirk in actual code, your code
needs so .to_i dropped in a few places. I'm actually surprised ruby
does those String=>Integer conversions at all.
 
L

L7

Wes said:
Thanks for the comprehensive response.

Well, I can't really argue with the C implementation, of course...

BUT

it feels like if I declare my intent to interpret the sprintf input as a
_decimal_ number with %d (there's a %o if I wanted octal), that is
should allow for leading zeroes.

My intent in writing sprintf("%d", '08') is to say take the string 08
and turn it into the number 8.

It isn't to say here's an octal number, please convert it to decimal for
me. If I think the string is octal, I'll use %o for that.

So in the spirit of what the user expects, I still think this smells
bad.

Feel free to convince me otherwise.

Consider it this way:

The format character (%d) is a way to know how the values collected
will be displayed. The values, in this case arguments to %d, are not
intrepreted (necessarily) at the same time as the format characters and
therefor are seperate entities. Taking any [legal] value and passing it
to %d will result in a decimal number printed out.
However, the parsing aspect is entirely different. There is no format
that says: 'this is how to interpret me' - other than the syntax.
If you take that away you create ambiguities. If the syntax is longer
how to distinguish a value, it must be explicitly tied to a format
string/character.

Imagine the confusion when you try to
#define FORTY_TWO_HEX %x 2a
#define FORTY_TWO_OCT %o 52
#define FORTY_TOW_DEC %d 42
(Since the two are now linked, you need the format characters. Or
should it be %x 42, %o 42 ... you get the idea)

instead of
#define FORTY_TWO_HEX 0x2a
#define FORTY_TWO_OCT 052
#define FORTY_TWO_DEC 42

While it may be easy/convenient to suggest allowing a format character
determine a value, it breaks when not in a specific setting.
 
W

Wes Gamble

I'll buy that. I did know that my input was a String so I am implicitly
asking for a conversion to occur.

Thanks for the discussion - it helps a lot.

Wes
 
X

Xavier Noria

When you use '%d' in a sprintf(), ruby does a conversion of the
argument to an Integer using Kernel#Integer and then does the
conversion of the Integer to a portion of the output string as
documented.

How did you figure that out? I started at sprintf.c and browsed a bit
around from rb_f_sprintf on, but I think I was in the wrong path. Or
is it the call to rb_str_to_inum equivalent to Kernel#Integer?

-- fxn
 
D

David Vallner

Wes said:
it feels like if I declare my intent to interpret the sprintf input as a
_decimal_ number with %d (there's a %o if I wanted octal), that is
should allow for leading zeroes.

Declare your intent by doing '08'.to_i(10) instead. In fact, declare
your intent in the first place that way.

Expecting sprintf to be automagical the way you expect out of two
incompatible, but perfectly valid interpretations isn't much to rely on.
Code everything explicitly and you'll get predictable results.

I'll join the club of people wondering why the String->Integer coercion
is happening in the first place.

David Vallner
 
H

Hal Fulton

Carlos said:
If _arg_ is a +String+, leading radix indicators (+0+, +0b+, and
+0x+) are honored.
[...]

so it's expected, documented, and consistent with c.


It is not expected, nor documented, because the documentation of sprintf
says:
d | Convert argument as a decimal number.

...which is very explicit in that the argument will be interpreted as a
decimal number, not octal.

The string of characters is interpreted as a decimal number IF IT IS
one. Since you started it with a zero, it's octal.

Hal
 
H

Hal Fulton

Wes said:
Thanks for the comprehensive response.

Well, I can't really argue with the C implementation, of course...

BUT

it feels like if I declare my intent to interpret the sprintf input as a
_decimal_ number with %d (there's a %o if I wanted octal), that is
should allow for leading zeroes.

My intent in writing sprintf("%d", '08') is to say take the string 08
and turn it into the number 8.

It isn't to say here's an octal number, please convert it to decimal for
me. If I think the string is octal, I'll use %o for that.

So in the spirit of what the user expects, I still think this smells
bad.

Feel free to convince me otherwise.

I see your point. But most things in Ruby that are stolen from C
behave JUST like the C counterparts. In fact, in many cases they
are just wrappers.

So I can understand why you don't like it. But my understanding
is that you should blame C.


Hal
 
H

Hal Fulton

Wes said:
I'll buy that. I did know that my input was a String so I am implicitly
asking for a conversion to occur.

Thanks for the discussion - it helps a lot.

Actually I failed to take that into account, so what I said
was half nonsense. :)

Hal
 
C

Carlos

Carlos said:
If _arg_ is a +String+, leading radix indicators (+0+, +0b+, and
+0x+) are honored.
[...]

so it's expected, documented, and consistent with c.


It is not expected, nor documented, because the documentation of sprintf
says:
d | Convert argument as a decimal number.

...which is very explicit in that the argument will be interpreted as a
decimal number, not octal.

The string of characters is interpreted as a decimal number IF IT IS
one. Since you started it with a zero, it's octal.

It's a string... I wanted this string formatted as a decimal number. Just
put these digits right justified in that other string. All this
behind-the-scenes conversion to integer is an implementation detail I should
not care about.

For that conversion, #to_i could have been used as well, and then '09' would
be interpreted as decimal 9. Why should I expect my string to be passed
through Integer() before formatting? That is not documented.

So, I expected
sprintf "%02d", "09" # => "09"

I see that none of you (except Wes) expected that, so, OK, my expectations
should be wrong. I really didn't expect _that_ (but I'm bad on expectations
:), I supposed that my expectations would be the majority, or that at
least 50% would expect something like #to_i.

But everyone expected Integer() and Integer() is what is used, and this took
nobody by surprise, so it's OK, I guess :)

Greetings.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,008
Latest member
Rahul737

Latest Threads

Top