«

John W. Krahn:

> $ perl -MPOSIX -le'print strtoul "ZZ", 36'
> 12950

Nice. But it acts weirdly on bad input:

$ perl -MPOSIX -le 'print strtoul "ZZ _", 36'
129514

$ perl -MPOSIX -le 'print strtoul "ZZ_________", 36'
12959

--
Affijn, Ruud

"Gewoon is een tijger."

Dr.Ruud wrote:
> John W. Krahn:
>
>>$ perl -MPOSIX -le'print strtoul "ZZ", 36'
>>12950
>
> Nice. But it acts weirdly on bad input:
>
> $ perl -MPOSIX -le 'print strtoul "ZZ _", 36'
> 129514
>
> $ perl -MPOSIX -le 'print strtoul "ZZ_________", 36'
> 12959

As the documentation explains, strtol and strtoul return two values.

$ perl -MPOSIX -le 'print for strtoul "ZZ _", 36'
1295
14


John
--
use Perl;
program
fulfillment

John W. Krahn:
> Dr.Ruud:
>> John W. Krahn:

>>> $ perl -MPOSIX -le'print strtoul "ZZ", 36'
>>> 12950
>>
>> Nice. But it acts weirdly on bad input:
>>
>> $ perl -MPOSIX -le 'print strtoul "ZZ _", 36'
>> 129514
>>
>> $ perl -MPOSIX -le 'print strtoul "ZZ_________", 36'
>> 12959
>
> As the documentation explains, strtol and strtoul return two values.
>
> $ perl -MPOSIX -le 'print for strtoul "ZZ _", 36'
> 1295
> 14

Aargh, I totally missed the order of magnitude from base36('ZZ') to
base10(12950).
For the next time: 36x36 is about 1000, not 10000.


It's a pity though that (yes, as the documentation says) it doesn't work
AIWLI beyond base 36:

$ perl -MPOSIX -le 'print scalar strtoul("ZZ", 62)'
2205

$ perl -MPOSIX -le 'print scalar strtoul("ZZ", 63)'
2240

$ perl -MPOSIX -le 'print scalar strtoul("zz", 62)'
2205

$ perl -MPOSIX -le 'print scalar strtoul("zz", 63)'
2240

--
Affijn, Ruud

"Gewoon is een tijger."

Dr.Ruud wrote:
> John W. Krahn:
>
> > $ perl -MPOSIX -le'print strtoul "ZZ", 36'
> > 12950
>
> Nice. But it acts weirdly on bad input:
>
> $ perl -MPOSIX -le 'print strtoul "ZZ _", 36'
> 129514
>
> $ perl -MPOSIX -le 'print strtoul "ZZ_________", 36'
> 12959

Not weird according to the docs. The second value
returned is the number of unparsed characters.

perl -MPOSIX -le'print join "\n", strtoul "ZZ", 36'
1295
0

FWIW, strtol ends at base 36. My interest in this
thread is that for some time I've used base 62 in a
bitvector database index compression/storage
scheme. It started as an experiment, but ended up
working rather nicely. I haven't hit the 2 billion record
mark, so overflow isn't yet an issue I've worried about.

--
Brad