07 is an integer but 08 isn't??
Michiel van Doorn
I'm using Tcl8.2 and using 'string is integer' to check if a string is an
integer. However,
[string is integer 07] returns 1 whether
[string is integer 08] returns 0
Why?
Michiel van Doorn
Allen Flick
'Cause the leading 0 says its Octal & since 08 is not valid
octal, then it's an invalid for a number. Therefore, it can't
be an integer if it's not a number.
=========================================
Allen Flick: Research is what I'm doing
when I don't know what I'm doing.
=========================================
Bob Techentin
>
> Hello,
>
> I'm using Tcl8.2 and using 'string is integer' to check if a string is an
> integer. However,
> [string is integer 07] returns 1 whether
> [string is integer 08] returns 0
>
> Why?
Strings with leading zeros are treated as octal, just as strings with a
leading "0x" are treated as hex. Check the Tcl Usage FAQ at
http://psg.com/%7Ejoem/tcl/faq.html for "Q.B10- How can I use numbers
with leading zeroes?" for workarounds.
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html
Jeffrey Hobbs
> I'm using Tcl8.2 and using 'string is integer' to check if a string is an
> integer. However,
> [string is integer 07] returns 1 whether
> [string is integer 08] returns 0
>
> Why?
Tcl 8.3 explains this quite well in the error message:
(tkcon) 49 % expr 08
"08" is an invalid octal number
--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.
DTAshley
microcontroller work, I have NEVER actually seen an octal number.
Even in assembly-language, every constant I normally work with is binary
(10101010%, for example), or hexadecimal (0FEh, for example), or decimal. The
closest I have ever come to an octal constant is reading in the assembler
documentation about how to declare an octal constant.
There must be some history about why octal constants were useful. But integers
expressed in base-8 seem to have gone the way of the pet rock ...
lvi...@cas.org
According to Bob Techentin <techenti...@mayo.edu>:
:leading "0x" are treated as hex. Check the Tcl Usage FAQ at
:http://psg.com/%7Ejoem/tcl/faq.html for "Q.B10- How can I use numbers
Anyone have an interest in updating the Tcl Usage FAQ? One of the things
that we probably can do is move info like this over into
http://dev.scriptics.com and open some gateways into co-moderatorship...
--
<URL: mailto:lvi...@cas.org> <URL: http://www.usenix.org/events/tcl2k/>
<*> O- <URL: http://www.purl.org/NET/lvirden/> Tcl2K - Austin, Texas, US
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
lvi...@cas.org
According to Darren New <dn...@san.rr.com>:
:> expressed in base-8 seem to have gone the way of the pet rock ...
:The difference, of course, is that in C, *only* literals got interpreted as
:octal without further specification. In Tcl, even numbers returned by [gets]
:get interpretered as octal. *That* is the real failure. At worst, it should
:have been 0o177 or something, similar to 0xFF.
:
Perhaps someone should write up a patch for Tcl to implement this behavior
and submit it?
Remember, Tcl is NOT a product of Scriptics. It is a community project.
It happens that Scriptics employees are most of the primary contributors.
But that need not continue to be the case - people can jump right in and
contribute in oh so many ways - write small "How Tos" on various Tcl topics.
Submit bug fixes for doc or code that doesn't work as documented. Submit
enhancements for Tcl missing behaviors or 'broken' behaviors. Sign up for
Tcl mailing lists working on various projects. Contribute code. Contribute
letters to the editor, book or software reviews, magazine articles,
news articles, press releases which mention Tcl, submit papers to conferences
(and tell us about them!).
There is unlikely to be any area of computing related endeavors in which
readers of this newsgroup are involved that doesn't have some way for readers
to contribute.
Todd M. Helfter
Tcl 8.3 If we have to use 0x to get hex, why don't we use Oo for octal???
--
.------------------------------.
| Todd M. Helfter |
| t...@purdue.edu |
| Database Analyst/Programmer |
| Purdue University |
`------------------------------'
Bob Techentin
>
> Tcl 8.3 If we have to use 0x to get hex, why don't we use Oo for octal???
Strings are converted to int through the POSIX strtoul() function. This
standard function recognizes leading "0x" for hex and leading "0" for
octal. Changing this would cause an incompatibility. I expect that
we'll just suffer the incompatability when we jump to Tcl 9.0.
Bryan Oakley
news:38B189CF...@mayo.edu...
> "Todd M. Helfter" wrote:
> >
> > Tcl 8.3 If we have to use 0x to get hex, why don't we use Oo for
octal???
>
> Strings are converted to int through the POSIX strtoul() function. This
> standard function recognizes leading "0x" for hex and leading "0" for
> octal. Changing this would cause an incompatibility. I expect that
> we'll just suffer the incompatability when we jump to Tcl 9.0.
That's just an excuse; it can easily be worked around. Count me in the camp
of those who think treating numbers with a leading zero as octal should go.
It's counter-intuitive to virtually everyone who uses tcl, including
*everyone* who is learning it for the first time.
Michiel van Doorn
38B189CF...@mayo.edu...
> "Todd M. Helfter" wrote:
> >
> > Tcl 8.3 If we have to use 0x to get hex, why don't we use Oo for
octal???
>
> Strings are converted to int through the POSIX strtoul() function. This
> standard function recognizes leading "0x" for hex and leading "0" for
> octal. Changing this would cause an incompatibility. I expect that
> we'll just suffer the incompatability when we jump to Tcl 9.0.
Incompatibility with how many programs? Or does the Eniac run tcl/tk?
Michiel van Doorn
Jeffrey Hobbs
> Can anyone please report if they
> ever use octal encoding or know of any one
> else using it on purpose? If a use *is*
> know please include some indication of
There's only one that I know of - file permissions, and that
feature in Tcl now also understands chmod *and* ls style
permissions settings. I wavered on taking it out for 8.3,
and worried a bit too much about those few silent people
who rely on it and would have a hell of a time figuring out
how to debug it once changed.
km...@socrates.berkeley.edu
DTAshley <dtas...@aol.com> wrote:
>
>There must be some history about why octal constants were useful.
>pet rock ...
In the early days of computing a byte wasn't always 8 bits. I've
personally used machines with both 6 bit and 9 bit bytes. (One
of the machine instructions had a bit that opted for 6 or 9 bits--and
that bit was called the "nine-bit-byte-bit").
With 6 or 9 bit bytes, then octal is more natural than hex.
Keith
Todd M. Helfter
on the left as the man page suggests.
0 Specifies that the number should be padded on the
left with zeroes instead of spaces.
so Tcl8.3
% format %03d 3
003
% format "%03d" 09
expected integer but got "09" (looks like invalid octal number)
% format "%03d" 08
expected integer but got "08" (looks like invalid octal number)
% format "%03d" 07
007
all expected results, except that to oracle/and oratcl think that 08 is just fine
as an integer.
Todd
P.S.
couldn't we patch chmod to accept the format mask as a character string?
Jeff David
>
> by leaving it in, this caused one of my scripts to break that wanted to pad with a 0
> on the left as the man page suggests.
>
> 0 Specifies that the number should be padded on the
> left with zeroes instead of spaces.
>
> so Tcl8.3
>
> % format %03d 3
> 003
> % format "%03d" 09
> expected integer but got "09" (looks like invalid octal number)
Then just change your format to use the %s instead of the %d specification:
% format "%03s" 09
009
Works like a charm.
Jeff David
jld...@lucent.com
Frank Pilhofer
> Then just change your format to use the %s instead of the %d specification:
> % format "%03s" 09
> 009
> Works like a charm.
But with interesting results if the numbers ever become negative.
Frank
--
+ Frank Pilhofer f...@informatik.uni-frankfurt.de +
| http://www.uni-frankfurt.de/~fp/ |
+---- Life would be a very great deal less weird without you. - DA ----+
Todd M. Helfter
In article <38B308B4.1D90@REMOVE_THISlucent.com>, Jeff David <jldavid@REMOVE_THISlucent.com> writes:
|> Todd M. Helfter wrote:
|> >
|> > by leaving it in, this caused one of my scripts to break that wanted to pad with a 0
|> > on the left as the man page suggests.
|> >
|> > 0 Specifies that the number should be padded on the
|> > left with zeroes instead of spaces.
|> >
|> > so Tcl8.3
|> >
|> > % format %03d 3
|> > 003
|> > % format "%03d" 09
|> > expected integer but got "09" (looks like invalid octal number)
|>
|>
|> % format "%03s" 09
|> 009
|>
|> Works like a charm.
|>
|> jld...@lucent.com
Jeff,
That is exactly what I did. I wasn't trying to appear whiney. Just point
out that an inconsistency in the documentation may exist.
Todd
Donal K. Fellows
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> Roy Terry wrote:
>> Can anyone please report if they ever use octal encoding or know of
>> any one else using it on purpose? If a use *is* know please include
>> some indication of
>
> There's only one that I know of - file permissions, and that feature
> in Tcl now also understands chmod *and* ls style permissions
> settings. I wavered on taking it out for 8.3, and worried a bit too
> much about those few silent people who rely on it and would have a
> hell of a time figuring out how to debug it once changed.
If you take it out when the major version changes (which should be
adequate warning for anyone who is currently relying on it) then I
think very few people will lose much sleep on the matter, especially
since they can always use [scan] to work around the problem.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
Bob Techentin
>
> Roy Terry wrote:
> > Can anyone please report if they
> > ever use octal encoding
>
> feature in Tcl now also understands chmod *and* ls style
> permissions settings. I wavered on taking it out for 8.3,
> and worried a bit too much about those few silent people
> who rely on it and would have a hell of a time figuring out
> how to debug it once changed.
Just forbid numeric modes with leading zeros (and without "0x" or
"0o"). I've attached a little patch, which presumes, of course, that
Tcl_GetLongFromObj() knows that "0o777" is octal. :-)
bo...@aol.com
Bob Techentin <techenti...@mayo.edu> wrote:
> This is a multi-part message in MIME format.
> --------------70009B79EE514F2CEA91E043
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Jeffrey Hobbs wrote:
> >
> > Roy Terry wrote:
> > > Can anyone please report if they
> > > ever use octal encoding
> >
> > There's only one that I know of - file permissions, and that
> > feature in Tcl now also understands chmod *and* ls style
> > permissions settings. I wavered on taking it out for 8.3,
> > and worried a bit too much about those few silent people
> > who rely on it and would have a hell of a time figuring out
> > how to debug it once changed.
>
> Just forbid numeric modes with leading zeros (and without "0x" or
> "0o"). I've attached a little patch, which presumes, of course, that
> Tcl_GetLongFromObj() knows that "0o777" is octal. :-)
>
> Bob
> --
> Bob Techentin
The present expr command also supports "0X' as a hex prefix. Did you
want to get rid of that? Of course you could add "0O" or just leave it
with "0x", "0X", and "0o". Huh?
bob
Sent via Deja.com http://www.deja.com/
Before you buy.
Bob Techentin
>
> The present expr command also supports "0X' as a hex prefix. Did you
> want to get rid of that? Of course you could add "0O" or just leave it
> with "0x", "0X", and "0o". Huh?
>
> bob
Actually, the patch I posted will generate an error message if you try
to pass a mode to [file attributes $filename -permissions xxxx] where:
the first character is a leading zero, and...
the second character is not a digit.
But it will pass a number without a leading zero, or numbers with
leading zeros where the second character is not a digit. So "0x", "0X",
"0o", and "0O" would all pass. It is then up to the numeric conversion
to catch legal radix operations. I personally think that it would be a
bad idea to use a leading zero and a capital oh ("O"), but that would be
up to the patch for tclGet.c
bo...@aol.com
Bob Techentin <techenti...@mayo.edu> wrote:
> bo...@aol.com wrote:
> >
> > The present expr command also supports "0X' as a hex prefix. Did you
> > want to get rid of that? Of course you could add "0O" or just leave it
> > with "0x", "0X", and "0o". Huh?
> >
> > bob
>
> Actually, the patch I posted will generate an error message if you try
> to pass a mode to [file attributes $filename -permissions xxxx] where:
>
> the first character is a leading zero, and...
> the second character is not a digit.
>
> But it will pass a number without a leading zero, or numbers with
> leading zeros where the second character is not a digit. So "0x", "0X",
> "0o", and "0O" would all pass. It is then up to the numeric conversion
> to catch legal radix operations. I personally think that it would be a
> bad idea to use a leading zero and a capital oh ("O"), but that would be
> up to the patch for tclGet.c
>
> Bob
> --
> Bob Techentin
Thinking out loud: What is the problem here anyway? It's with the way
expr handles octal radix conversions. Many people have complained about
that. A change is called for. Fewer complaints if this is changed.
File permissions: Few if any have complained about the way file
permissions are handled. I suspect if a change is made to this, there
will be many. Remember, every time someone writes a file permission
code, they will have to do it different from older versions of tcl and
from other shells/languages.
Conclusion: Minimum complaints will be had by changing expr alone and
keeping the leading zero feature for permissions. I know this means two
different methods in the same language. It means not having a
'standard' for octal. It is a compromise.
OTH: If you do it this way the complaints go away because no-one uses
the octal radix conversion in expr. Lots of people use octal numbers
with file permissions and they will just go along without being
impacted. This will be forgotton a few months after it is implemented.
Change the file permissions and you will have some angry posts for a
long time. (I predict).
Cheers
Bob Techentin
>
> Thinking out loud: What is the problem here anyway? It's with the way
> expr handles octal radix conversions.
Errr. That's not the way I have been thinking about it. Maybe I made
the mistake of reading the Tcl core source code, but I have been
thinking of it in terms of Tcl's conversion from string to integer.
Several commands rely upon this conversion (regexp, upvar, string,
etc.). It isn't limited to just [expr].
I think the distinction is that the [file attributes] command is the
only one where anybody ever thinks of using octal, so this is where you
might find legacy codethat includes an octal literal.
Bryan Oakley
> Conclusion: Minimum complaints will be had by changing expr alone and
> keeping the leading zero feature for permissions. I know this means two
> different methods in the same language. It means not having a
> 'standard' for octal. It is a compromise.
I see no compromise here, just a matter of documentation. chmod should be
documented as taking a string of octal digits, which shouldn't be confused
with a number that is defined with octal notation. In other words, don't
allow an integer for specifying permissions -- require a string. Since, in
tcl, "everything's a string", this should be simply a matter of
documentation (and fixing the file command to convert the string to the
right set of bits). This also lets one specify octal permissions without a
leading zero (ie: 666 will work just fine; no need for 0666).
bo...@aol.com
Bob Techentin <techenti...@mayo.edu> wrote:
> bo...@aol.com wrote:
> >
> > Thinking out loud: What is the problem here anyway? It's with the way
> > expr handles octal radix conversions.
difficulty with'.
>
> Errr. That's not the way I have been thinking about it. Maybe I made
> the mistake of reading the Tcl core source code, but I have been
> thinking of it in terms of Tcl's conversion from string to integer.
> Several commands rely upon this conversion (regexp, upvar, string,
> etc.). It isn't limited to just [expr].
solution. If it affects regexp, upvar, string, and other things that
were not reported on as part of the problem, it probably isn't a good
one.
>
> I think the distinction is that the [file attributes] command is the
> only one where anybody ever thinks of using octal, so this is where you
> might find legacy codethat includes an octal literal.
>
> Bob
> --
> Bob Techentin
code. I don't have the time or interest for that. I did, however, want
to contribute something to the end result.
Bob Techentin
>
> <bo...@aol.com> wrote in message news:89jif1$skq$1...@nnrp1.deja.com...
> > Conclusion: Minimum complaints will be had by changing expr alone and
> > keeping the leading zero feature for permissions. I know this means two
> > different methods in the same language. It means not having a
> > 'standard' for octal. It is a compromise.
>
> I see no compromise here, just a matter of documentation. chmod should be
> documented as taking a string of octal digits, which shouldn't be confused
> with a number that is defined with octal notation.
Hmmmm. I like that idea. Actually, the documentation with Tcl 8.3.0
already says that:
-permissions sets or retrieves the octal code that chmod(1) uses.
That would be an even shorter patch than the one I posted. The existing
Tcl core is arguably wrong today, because you can use the command:
file attributes myfile.dat -permissions 188
(which is the same as 00274, but not octal by a long stretch.)
How does this patch look?
Peter V. Morch
> Can anyone please report if they
> ever use octal encoding
> Roy "octal should go" Terry
I have never come across any octal numbers either.
Since this thread seems to be considering making changes in this area, I
just thought you would be dying to hear my $0.02 ;-):
Using binary numbers all the time, I would *love* to see:
set a [expr 0b100101]
puts [ format "The binary representation of $a is: %b" $a]
(similar for scan)
Of course I am being naive when not attaching a patch that actually does
this, but in my opinion this would be wonderful. ;-) Any idea how
difficult this would be to implement?
Am I the only one that would find this incredibly useful?
Here and in previous jobs, I always seem to end up using hex digits, &
and | when they aren't really handy.
Peter "Binary should come" Morch
Tom Wilkason
We use (and rely on) octal numbers for one of our applications that talks
with a vintage computer via a custom interface. Re. binary, it is not much
work to write a tcl command in C to convert to/from binary.
Tom Wilkason
Peter V. Morch <pmo...@cisco.com> wrote in message
news:38BDA76E...@cisco.com...
Steve Blinkhorn
than in decimal, hex or binary (and easier to OR codes in your head).
Remember TOPS-10? Bring back SIXBIT I say...... ;-)
--
Steve Blinkhorn <st...@prd.co.uk>
Jeff David
>
> Since this thread seems to be considering making changes in this area, I
> just thought you would be dying to hear my $0.02 ;-):
>
> Using binary numbers all the time, I would *love* to see:
>
> set a [expr 0b100101]
> puts [ format "The binary representation of $a is: %b" $a]
> (similar for scan)
>
> Of course I am being naive when not attaching a patch that actually does
> this, but in my opinion this would be wonderful. ;-) Any idea how
> difficult this would be to implement?
>
proc bin_to_dec {b} {
set blen [string length $b]
# Left pad the binary string to a multiple of 8
set f [expr {$blen + 8 - $blen % 8}]
# Convert to hex
binary scan [binary format B* [format %0${f}s $b]] H* h
# Return an unsigned integer. Note that if the binary
# string is > 32 bits, tcl will return an "integer value
# too large to represent" error.
return [format %u 0x$h]
}
% bin_to_dec 100101
37
% bin_to_dec 111110001
497
Jeff David
jld...@lucent.com
Bob Techentin
>
> Roy,
> We use (and rely on) octal numbers for one of our applications that talks
> with a vintage computer via a custom interface. Re. binary, it is not much
> work to write a tcl command in C to convert to/from binary.
Tom,
You are the first person that I have *ever* heard make this claim. Not
that I'm some sort of radix bigot. :-) I have fond memories of
toggling in the bootstrap code on a PDP 11/34, but I haven't seriously
used octal in more than a decade. Now that I am aware of at least one
person who works on an application that really requires octal, I have
only one question:
How bad will it be for you when we change the Tcl core to interpret
literal integers with leading zeros as decimal, and introduce a new
prefix for literal octals? Could somebody bang out a script that would
check source code for words with leading zeros that might be intended as
octal constants? Is your usage of octal consistent enough that it could
be discovered and/or corrected programmatically?
(O.K. It was more than one question.)
Note: You would have to change string constants like "0777" to "0o777",
but commands like expr, scan and format would still work the same on
numbers.
Richard.Suchenwirth
> proc bin_to_dec {b} {
> set blen [string length $b]
> # Left pad the binary string to a multiple of 8
> set f [expr {$blen + 8 - $blen % 8}]
> # Convert to hex
> binary scan [binary format B* [format %0${f}s $b]] H* h
> # Return an unsigned integer. Note that if the binary
> # string is > 32 bits, tcl will return an "integer value
> # too large to represent" error.
> return [format %u 0x$h]
> }
>
proc bin2int s {
if ![regexp {^[01]*$} $s] {error "expected 0/1 string but got $s"}
set x 1
set res 0
foreach i [split [string:revert $s] ""] {
if {$i==1} {incr res $x}
incr x $x
}
set res
}
where
proc string:revert {s} {
set res ""
foreach i [split $s ""] {set res $i$res}
set res
}
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens Electrocom, Buecklestr. 1-5, D-78467 Konstanz,Germany
-------------- http://purl.org/thecliff/tcl/wiki//Richard*Suchenwirth
Bryan Oakley
[snip]
> That would be an even shorter patch than the one I posted. The existing
> Tcl core is arguably wrong today, because you can use the command:
>
> file attributes myfile.dat -permissions 188
>
> (which is the same as 00274, but not octal by a long stretch.)
Personally I think the above (using 188 for the permissions value) should
*not* be allowed. permissions should take a valid octal string *only*.
Having the file command treat the value as a string of digits instead of a
number would fix that, and would be a definite Good Thing in my opinion.
Jeffrey Hobbs
> Tom Wilkason wrote:
> > We use (and rely on) octal numbers for one of our applications that talks
> > with a vintage computer via a custom interface. Re. binary, it is not much
> > work to write a tcl command in C to convert to/from binary.
> You are the first person that I have *ever* heard make this claim. Not
> that I'm some sort of radix bigot. :-) I have fond memories of
...
> How bad will it be for you when we change the Tcl core to interpret
> literal integers with leading zeros as decimal, and introduce a new
> prefix for literal octals? Could somebody bang out a script that would
Note that this is exactly the reason why we can't just arbitrarily
make the octal interpretation change. One voice on the newsgroup
can represent countless others that use it quietly elsewhere. The
ratio of newsgroup Tcl users to real Tcl users is quite small,
which is why such changes have to occur in major versions. It
should really have happened with Tcl8, but no we only have Tcl9 to
think about.
Bob Techentin
>
> It should really have happened with Tcl8, but no we only
> have Tcl9 to think about.
Hot diggity dog. And when are we going to do Tcl9? (I'll try writing a
patch. But I'd like to know how long I've got to rework the test cases.
:-)
Tom Wilkason
situations. The current TCL interpretation of decimal, octal and hex numbers
follows the ANSI C specification (except for the rejection of 08 & 09), and
I am wondering why we would want to change it. Did I miss something?
Tom Wilkason
Bob Techentin <techenti...@mayo.edu> wrote in message
news:38BE8B38...@mayo.edu...
> Tom Wilkason wrote:
> >
> > Roy,
> > We use (and rely on) octal numbers for one of our applications that
talks
> > with a vintage computer via a custom interface. Re. binary, it is not
much
> > work to write a tcl command in C to convert to/from binary.
>
> Tom,
>
> You are the first person that I have *ever* heard make this claim. Not
> that I'm some sort of radix bigot. :-) I have fond memories of
> toggling in the bootstrap code on a PDP 11/34, but I haven't seriously
> used octal in more than a decade. Now that I am aware of at least one
> person who works on an application that really requires octal, I have
> only one question:
>
> How bad will it be for you when we change the Tcl core to interpret
> literal integers with leading zeros as decimal, and introduce a new
> prefix for literal octals? Could somebody bang out a script that would
> check source code for words with leading zeros that might be intended as
> octal constants? Is your usage of octal consistent enough that it could
> be discovered and/or corrected programmatically?
>
> (O.K. It was more than one question.)
>
> Note: You would have to change string constants like "0777" to "0o777",
> but commands like expr, scan and format would still work the same on
> numbers.
>
Bob Techentin
>
> This sounds to me as one of those "if it ain't broke, don't fix it"
> situations. The current TCL interpretation of decimal, octal and hex numbers
> follows the ANSI C specification (except for the rejection of 08 & 09), and
> I am wondering why we would want to change it. Did I miss something?
>
"It ain't broke" if you are programming in C, where a literal 0xFF or
literal 0777 has a context. These are integers. They appear only in
source code. They work fine. The functions atoi()/atol() etc. assume
decimal, and while sscanf() is flexible, you must be explicit. If you
want to translate a "string" of digits into an integer, and you want to
automatically interpret the leading "0", you must go to some effort to
invoke strtol()/strtoul() passing in a base of zero. (BTW: this fails
for "08".)
Tcl, on the other hand, is not C, and it is broke. Integers in Tcl are
also strings, and it is much more common to accidentally end up with a
number string with a leading zero when the programmer never intended
octal conversion. These accidents can come from scanning [clock]
values, formatted data strings like "FILE0001.DAT", or even from user
input. In these cases, Tcl will often silently convert the number
string to octal, and do the Wrong Thing (tm) until it fails on an "8" or
"9".
When this unexpected failure occurs, the user or programmer then reports
a bug to comp.lang.tcl. The response is "use this regular expression to
strip leading zeros." Baaaahhhh! Tcl is broke. It should be fixed for
version 9.0.
My question still stands. How hard will it be for you to fix your code
for Tcl 9.0, replacing and reformatting octal values from "0777" to
"0o777"?
Donal K. Fellows
Steve Blinkhorn <st...@sole.prd.co.uk> wrote:
> Somehow, it's much easier to remember ASCII character codes in octal
> than in decimal, hex or binary (and easier to OR codes in your head).
Speak for yourself. I find it easier to remember ASCII (or at least
those bits of it that I need) as hex. I suspect this may be true for
a great many other younger programmers too.
It would be uncharitable for me to suggest that octal remains in Tcl
solely to support old fogeys... >:^)
bo...@aol.com
"Tom Wilkason" <wilk...@hom.net> wrote:
> This sounds to me as one of those "if it ain't broke, don't fix it"
> situations. The current TCL interpretation of decimal, octal and hex numbers
> follows the ANSI C specification (except for the rejection of 08 & 09), and
> I am wondering why we would want to change it. Did I miss something?
>
I think you missed a lot of discussions here in c.l.t. :-)
In c if you have an expression such as '(a+b)/c' the result depends
only on the values of a b and c. In tcl '($a+$b)/$c' produces a result,
but radix conversions can change the result! Combine this with the
'normal' interpretation of leading zeros in decimal numbers and you have
the source of a lot of programming errors.
Take a typical date such as '09/28/2000'. 09 is accepted as a decimal
(not octal) number, so if you are parsing this to do some calculations
it is easy to forget that, in tcl, you must first strip the leading
zeros(if any).
If you want to make tcl work like c, technically you could change it so
expr would only convert literals. For example:
expr {($a+$b)/($c+0342)}
must only apply radix conversion to the literal.
Unfortunately this would break everything and require too many changes
to programming practices and existing applications. Therefore it has
been proposed that '0o' be adopted as the octal prefix instead of '0'.
This means that applications which use octal will need to be made
compatible with this new feature when they update to new releases of
tcl, unless provisions are made to continue support for the old method.
Tom Wilkason
Under the situation you describe, it can be painful not having the right of
first refusal to tell the parser to interpret integers as decimal. What I
ususally do when reading in external data that has leading zeros is run it
through the scan statement:
set dateToTry "09/27/99"
scan $dateToTry "%d/%d/%d" day month year
This insures I get decimal. However, there are still cases where this may
not work or is very cumbersome. I recommend for the next TCL release a new
switch be added (via the same method as tcl_precision is done) to tell the
parser to consume leading zeros when parsing numbers (tcl_consumeZeros ??),
also add the 0oxxxx and 0bxxxx formats as many have requested. The default
for tcl_consumeZeros could be 1 which would mean that when upgrading to the
new version of TCL you may have to modify your code (set tcl_consumeZeros 0)
if you assume leading 0's are octal. This would make life easier for the few
of us that have legacy code that assumes octal numbers have leading zeros.
Any ideas?
Tom Wilkason
<bo...@aol.com> wrote in message news:89os14$njv$1...@nnrp1.deja.com...
David LeBlanc
c.l.t.
Personally, I do like the notion of 0o, 0b, 0x (and for completeness)
0d (ooh is it decimal or hex - same for the 0b case?).
Another notion is to have arbitrary radices of the form:
[A-Z0-9]*r[0-9a-zA-Z]+ or 1234r19 for example with the value following
"r" usually limited to 36 to include all the (upper case) alphabet and
decimal digits. Of course, it does complicate recognition of literals
at least until the 'r' is seen. It also means that hex has to be caps
in this context which some people hate. Smalltalk has this syntax but
I think it's more fluffery then really useful for 0d99.9% of all
cases.
It seems to me that the best arguement for decimal being the default
unless denoted otherwise is that tcl has moved from it's roots as a
bit twiddling language used by systems programmers to one that is
seeing a lot more use by applications oriented programmers who live
more in a decimal world. (Let us not forget the systems programmers of
the world by any means - some of whom have kilo-lines of testing code
that might very well rely on 0777 being octal.)
Dave LeBlanc
On Wed, 01 Mar 2000 15:27:42 -0800, "Peter V. Morch"
<pmo...@cisco.com> wrote:
>Roy Terry wrote:
>> Can anyone please report if they
>> ever use octal encoding
><snip>
>> Roy "octal should go" Terry
>
>I have never come across any octal numbers either.
>
>Since this thread seems to be considering making changes in this area, I
>just thought you would be dying to hear my $0.02 ;-):
>
>Using binary numbers all the time, I would *love* to see:
>
>set a [expr 0b100101]
>puts [ format "The binary representation of $a is: %b" $a]
>(similar for scan)
>
>Of course I am being naive when not attaching a patch that actually does
>this, but in my opinion this would be wonderful. ;-) Any idea how
>difficult this would be to implement?
>
bo...@aol.com
"Tom Wilkason" <wilk...@hom.net> wrote:
> Bob,
> Under the situation you describe, it can be painful not having the right of
> first refusal to tell the parser to interpret integers as decimal. What I
> ususally do when reading in external data that has leading zeros is run it
> through the scan statement:
>
> set dateToTry "09/27/99"
> scan $dateToTry "%d/%d/%d" day month year
>
don't come from expr. This is quite a burden to put on 99.9+% of
applications that don't use octal so the ones that do can use a leading
zero convention that was designed for another language.
>
> This insures I get decimal. However, there are still cases where this may
> not work or is very cumbersome. I recommend for the next TCL release a new
> switch be added (via the same method as tcl_precision is done) to tell the
> parser to consume leading zeros when parsing numbers (tcl_consumeZeros ??),
> also add the 0oxxxx and 0bxxxx formats as many have requested. The default
> for tcl_consumeZeros could be 1 which would mean that when upgrading to the
> new version of TCL you may have to modify your code (set tcl_consumeZeros 0)
> if you assume leading 0's are octal. This would make life easier for the few
> of us that have legacy code that assumes octal numbers have leading zeros.
>
> Any ideas?
>
> Tom Wilkason
>
of applications that don't use octal to carry around an option with some
extra complexity and(small) extra overhead to support it for backward
compatibility.
What if you wrote a little script to update your code that uses regexp
to find the octal contants and regsub to change them to the '0o' prefix?
The script could print out the original line and the updated line. It
could have an '-rpt' option and a '-query' option. If you run it with
the '-rpt' option it displays original and updated lines for each line
it proposes to change. With the -query option it will ask you if you
want the change for each instance.
Of course I can't see your application, but it doesn't seem like it
would be that difficult to change.
Another way would be to have a tcl8.3 package which has tcl8.3::expr,
if, while, etc. in it which you could load if you want the previous
octal feature. That the burden is put only on apps that want the old
feature. This might be a difficult thing to do. I don't know.
Paul Duffin
>
> Bob,
> Under the situation you describe, it can be painful not having the right of
> first refusal to tell the parser to interpret integers as decimal. What I
> ususally do when reading in external data that has leading zeros is run it
> through the scan statement:
>
> set dateToTry "09/27/99"
> scan $dateToTry "%d/%d/%d" day month year
>
> not work or is very cumbersome. I recommend for the next TCL release a new
> switch be added (via the same method as tcl_precision is done) to tell the
> parser to consume leading zeros when parsing numbers (tcl_consumeZeros ??),
> also add the 0oxxxx and 0bxxxx formats as many have requested. The default
> for tcl_consumeZeros could be 1 which would mean that when upgrading to the
> new version of TCL you may have to modify your code (set tcl_consumeZeros 0)
> if you assume leading 0's are octal. This would make life easier for the few
> of us that have legacy code that assumes octal numbers have leading zeros.
>
> Any ideas?
>
The problem with that approach is that you cannot get two different packages
which want different behaviour to work together properly without modifying one
or the other and it may be difficult to find all the places in the source
code which need to check this, it may all be restricted to Tcl_GetIntFromObj
and TclLooksLikeAnInt.. which would not be too difficult.
I personally think that we should stop using a leading 0 as an indicator of
octalness, instead use 0o or something else and just take the pain. Of course
I would say that as I do not rely on octal anyway ;-).
What do Python and Perl do for this ?
Bob Techentin
>
> What do Python and Perl do for this ?
Both Python and Perl support the leading zero syntax for octal
constants. But they also appear to rely on conversion functions to get
numbers from strings, like python's int() which is decimal and eval()
which would interpret the leading zero.
Richard.Suchenwirth
>
> Paul Duffin wrote:
> >
> > What do Python and Perl do for this ?
>
> Both Python and Perl support the leading zero syntax for octal
> constants. But they also appear to rely on conversion functions to get
> numbers from strings, like python's int() which is decimal and eval()
> which would interpret the leading zero.
>
suchenwi@jaguar% gawk 'BEGIN{print 099}'
99
suchenwi@jaguar% gawk 'BEGIN{print 0099+1}'
100
--
Schoene Gruesse/best regards, Richard Suchenwirth - +49-7531-86 2703
RC DT2, Siemens Electrocom, Buecklestr. 1-5, D-78467 Konstanz,Germany
-------------- http://purl.org/thecliff/tcl/wiki//Richard*Suchenwirth
AL:The Analytical Engine worketh not!CB:What version doest thou have?
Cameron Laird
Paul Duffin <pdu...@hursley.ibm.com> wrote:
.
.
.
>What do Python and Perl do for this ?
It's the same in Python. A numeral which begins with 0 is octal;
09 + 1
is a syntax error. However, people stumble over this about two
orders of magnitude less often in Python than in Tcl. I regard
this more as a happy contingent fact for Python, than a virtue
which should inspire Tcl's shame. The essence of the difference
is that Python has types, so "01234" is recognized as a string
and 01234 is a number.
Incidentally, Python has been willing to break backward compati-
bility; the atoi() built-in originally interpreted "01234" as octal.
Perl numbers also interpret leading zero as an octal marker. More-
over, "\075" is a string specified with an octal value; in that use,
the numeral is two- or three-digit (that is, only as one- or two-
significant-digit values). Again, Perl distinguishes strings and
numbers.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Mark Harrison
> When this unexpected failure occurs, the user or programmer then reports
> a bug to comp.lang.tcl. The response is "use this regular expression to
> strip leading zeros."
And don't forget the followup discussion, when the obvious regular
expression breaks the value "0".
Mark.
--
Mark Harrison ma...@usai.asiainfo.com
AsiaInfo Computer Networks http://www.markharrison.net
Beijing / Santa Clara http://usai.asiainfo.com:8080