# solving the 0ctal problem

5 views

### Jeffrey Hobbs

May 31, 1999, 3:00:00 AM5/31/99
to
While reading some docs for another language, I came across a flash
of insight about fixing the octal problem in an "easy" manner.
to the expr command? Since people are only really seem to be
encountering this problem in exprs anyway, it seems like a good
fit. For most, you would just wrap the desired number in dec()
(or base(10,int)) to make sure it was interpreted as a decimal num.

That way people only have to know that possibly suspicious numbers
(like those entered by users) that are meant to be decimals can
be guaranteed to be interpreted as such with the above.

--
** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **
** I'm really just a Tcl-bot My opinions are MY opinions **

Jeffrey.Hobbs.vcf

### Volker Hetzer

May 31, 1999, 3:00:00 AM5/31/99
to
Jeffrey Hobbs wrote:
>
> While reading some docs for another language, I came across a flash
> of insight about fixing the octal problem in an "easy" manner.
> to the expr command? Since people are only really seem to be
> encountering this problem in exprs anyway, it seems like a good
> fit. For most, you would just wrap the desired number in dec()
> (or base(10,int)) to make sure it was interpreted as a decimal num.
>
> That way people only have to know that possibly suspicious numbers
> (like those entered by users) that are meant to be decimals can
> be guaranteed to be interpreted as such with the above.
Great!
One could even think of the same stuff for doubles.

Greetings!
Volker

### Roy Terry

May 31, 1999, 3:00:00 AM5/31/99
to
As much as I appreciate the suggestion, it seems like
a band-aid. The worst aspect of the "octal problem" is that
it takes people by surprise; "dec()" doesn't help that situation
at all.

Sometimes historical baggage should just be jettisoned.
My favorite is add a switch to preserve the old behavior and
let the people who know and care about octal handle it. I'm sure
they're capable.

-Roy

Jeffrey Hobbs wrote:
>
> While reading some docs for another language, I came across a flash
> of insight about fixing the octal problem in an "easy" manner.
> to the expr command? Since people are only really seem to be
> encountering this problem in exprs anyway, it seems like a good
> fit. For most, you would just wrap the desired number in dec()
> (or base(10,int)) to make sure it was interpreted as a decimal num.
>
> That way people only have to know that possibly suspicious numbers
> (like those entered by users) that are meant to be decimals can
> be guaranteed to be interpreted as such with the above.
>

### Andreas Kupries

May 31, 1999, 3:00:00 AM5/31/99
to
Jeffrey Hobbs <Jeffre...@icn.siemens.de> writes:

> While reading some docs for another language, I came across a flash
> of insight about fixing the octal problem in an "easy" manner. What
> expr command?

I like it.

> encountering this problem in exprs anyway,

Or 'incr'.

--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.westend.com/~kupries/>
-------------------------------------------------------------------------------

### Andreas Kupries

May 31, 1999, 3:00:00 AM5/31/99
to

Volker Hetzer <volker...@abg1.siemens.de> writes:
> Jeffrey Hobbs wrote:

>> While reading some docs for another language, I came across a flash
>> of insight about fixing the octal problem in an "easy" manner.

>> to the expr command? Since people are only really seem to be
>> encountering this problem in exprs anyway, it seems like a good
>> fit. For most, you would just wrap the desired number in dec() (or
>> base(10,int)) to make sure it was interpreted as a decimal num.

>> That way people only have to know that possibly suspicious numbers
>> (like those entered by users) that are meant to be decimals can be
>> guaranteed to be interpreted as such with the above.

> Great!

> One could even think of the same stuff for doubles.

Hm, we already have conversion functions in 'expr' for this:

double(arg)
If arg is a floating value, returns arg, otherwise
converts arg to floating and returns the converted
value.
and

int(arg)
If arg is an integer value, returns arg, otherwise
converts arg to integer by truncation and returns
the converted value.

### Volker Hetzer

Jun 1, 1999, 3:00:00 AM6/1/99
to
Andreas Kupries wrote:
>
> Volker Hetzer <volker...@abg1.siemens.de> writes:
> > Jeffrey Hobbs wrote:
> > [Solution to the octal problem]

> > Great!
> > One could even think of the same stuff for doubles.
>
> Hm, we already have conversion functions in 'expr' for this:
>
> double(arg)
> If arg is a floating value, returns arg, otherwise
> converts arg to floating and returns the converted
> value.
Yes, but what about a floating hex number?
double(0xAF.E), or double(0xAF.FE-15)?
Jeffs solution would work if it would scan for the . and the exponent.
hex(AF.ee-15) could return an appropriate double. I see applications
of this in embedded solutions.

Greetings!
Volker

### bo...@aol.com

Jun 6, 1999, 3:00:00 AM6/6/99
to

> As much as I appreciate the suggestion, it seems like
> a band-aid. The worst aspect of the "octal problem" is that
> it takes people by surprise; "dec()" doesn't help that situation
> at all.
>
> Sometimes historical baggage should just be jettisoned.
> My favorite is add a switch to preserve the old behavior and
> let the people who know and care about octal handle it. I'm sure
> they're capable.
>
> -Roy
I agree with this.

The original "octal problem" is "unwanted octal conversions" performed
by the expr command. Basicly, since expr performs substitutions before
number conversions, expr converts numbers stored in variables to decimal
in addition to literals. There was another thread that seemed to have
this problem solved by eliminating octal conversions from expr.

Once expr no longer performs octal conversions, and if people still need
to use octal numbers, there needs to be a way to do it. scan can be
used and this may be sufficient since octal numbers are littled used.

If you want to look at the way other languages handle this, look at C.
When an octal literal is coded in C it is converted to an integer and
used in context. This would be typically in expressions, simple
replacements (i=017) and as function arguments.

Now consider what tcl does. For example:

1) set foo 0177
2) set result [expr \$foo+24]

tcl performs the conversions in expr after substitution. This creates
the illusion that a conversion was performed at 1). Of course there was
no conversion at 1). The price of this illusion is high since it
introduces the problem that the contents of all variables are subjected
to base conversions.

A way to make tcl perform like C in this respect is to add a 'base'
command that converts numbers in other bases to decimal. The 'base'
command would also create lists when a list of numbers is provided as
arguments. For example:

set foo [base 0177] ;# initialization or simple replacement
set num_list [base 0177 0xA1 99];# convert a list of numbers to decimal
set result [expr \$foo+24+[base 0xBC2]] ;# expr does no conversions
foobar [base 0xAB13] "a string" # function(proc) call argument

While this is more verbose than other languages it lets you make the
convesions you need explicitly and put them where they need to go. The
verboseness is the price of a minimal interpreter has a minor benefit of

Of course you can't really get rid of the 0x conversions done by expr
because they are already heavily used and this will cause code breakage.

Bob

>
> Jeffrey Hobbs wrote:
> >
> > While reading some docs for another language, I came across a flash
> > of insight about fixing the octal problem in an "easy" manner.
> > to the expr command? Since people are only really seem to be
> > encountering this problem in exprs anyway, it seems like a good
> > fit. For most, you would just wrap the desired number in dec()
> > (or base(10,int)) to make sure it was interpreted as a decimal num.
> >
> > That way people only have to know that possibly suspicious numbers
> > (like those entered by users) that are meant to be decimals can
> > be guaranteed to be interpreted as such with the above.
> >

> > --
> > ** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **
> > ** I'm really just a Tcl-bot My opinions are MY opinions **
>
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.