Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not allow 0... syntax for octal #151

Closed
gopherbot opened this issue Nov 13, 2009 · 13 comments
Closed

Do not allow 0... syntax for octal #151

gopherbot opened this issue Nov 13, 2009 · 13 comments

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 13, 2009

by notan.kdev:

What steps will reproduce the problem?
1. Enter a list of numbers 
     1230,
     0123,
     3012,
     2301
guess what went wrong.


Starting octal number with a 0 prefix is a pain.
You should make it a syntax error, or at least it is worth a warning.
If somebody really needs octal allow 
0o123 
which is consistent to the hex notation 0x123
   ( 0b0101 for binary would be handy sometimes, 
     0d0123 for decimal may make the syntax complete)
@robpike
Copy link
Contributor

@robpike robpike commented Nov 13, 2009

Comment 1:

Status changed to LongTerm.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 15, 2009

Comment 2 by autophile:

This is hardly a problem unique to Go. You'd get the same issue in C, C++, or Java.
Although I agree that binary 
literals would be very convenient to help with bit twiddling.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 17, 2009

Comment 3 by JQBalter:

For a new language that is trying to avoid some of the problems of languages like C,
C++, and Java, pointing out that those languages have some problem is hardly a reason
not to eliminate the problem.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 18, 2009

Comment 4 by yukuku:

I agree with disallowing 0... syntax for octal. I couldn't think a reason we need
octal numbers beside for chmod(file, 0755).
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 18, 2009

Comment 5 by dschauer:

@OP, I agree, even though decimal is the default, since we already have 0x, we need
0b, 0o, and 0d, since those are the most common bases used in computer programming.
Go is a fresh start, it would be best to avoid all the previous confusion and
problems caused by leading 0s being octal. I see no problem with having to use 0o0644
for a file permission even if it looks kind of funny.
@robpike
Copy link
Contributor

@robpike robpike commented Nov 18, 2009

Comment 6:

We have talked this over a lot and decided that, although it might have been better to
leave octal out 
from the beginning, taking it out has major consequences and compensating for its
removal will make 
the language uglier. First, if octal goes away then we would want to forbid leading
zeros in decimal 
numbers because people porting  or interfacing to C code, or even people used to writing
C code, would 
have uncaught subtle errors.  That alone makes the opening argument in the discussion
less convincing: 
remove octal so we can have leading zeros, but then we can't have leading zeros because
of the bugs 
that come in.  One could argue that the bugs are limited in scope, but they will happen
and be hard to 
find.
And if we're going to play with radix changes for inputting numbers, we would want to
fix the problem 
once and for all, with something like 16r8000 and 8r377, but those don't sit right;
they're just ugly.  Of 
course one could grandfather 0x but then there are two unrelated notations for numbers,
and that's bad.
Finally, can we remove octal from character and string constants?  If not, there's an
inconsistency that's 
troubling.  The relationship between char constants, string constants, and integer
constants is a careful 
balance and this gets us in unsettling territory.
So after a long discussion, we've decided to leave the status quo, which is familiar to
everyone, because 
the fix seems to make things more uglier and more complicated rather than simpler.

Status changed to WontFix.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 19, 2009

Comment 7 by FlyMyPG:

Sure, keep the legacy octal syntax.  But that's not a reason NOT to also add a more 
explicit syntax.
Add a compiler flag to warn about the risky/legacy numeric literals (including stuff 
like "0O", if possible in the new syntax), and add a flag to gofmt to permit auto-
conversion to the most explicit syntax.
Then wait a year, grep the Go application base, and check the ratio of legacy octals 
to "new" octals.  If "new" octals dominate heavily, only then would it be useful to 
consider deleting the legacy octal syntax from Go.
@gopherbot
Copy link
Author

@gopherbot gopherbot commented Nov 19, 2009

Comment 8 by gherald:

Agreed with the above.  Even if you persist with a blanket 'design decision'
precluding warnings for legacy octal, a new systems language ought to have an
explicit alternative like 0o--and more usefully, 0b for binary and optional _ separators.
@gopherbot gopherbot added the wontfix label Nov 19, 2009
@jasonpfox
Copy link

@jasonpfox jasonpfox commented Jun 15, 2016

I am just starting to work in Go and this is the first thing I have come across that appears as an actual bug in the language and I can't believe it had been reviewed and accepted "Won't Fix" just because others had jumped off that bridge before.

Talk about uncaught subtle errors ... 045 is a completely legitimate decimal number (and is even often written that way as a decimal in many forums, such as when talking about a course or heading among others). Interpreting a legitimate decimal constant as octal just because of a leading 0 is mathematically wrong and misleading, even if other languages have done that before.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 15, 2016

@jasonpfox There is no point to having a discussion on a closed issue. See https://golang.org/wiki/Questions .

@jasonpfox
Copy link

@jasonpfox jasonpfox commented Jun 15, 2016

So how do we get the issue reopened?

Jason Fox

jpfox@alumni.rice.edu

On Wed, Jun 15, 2016 at 2:23 PM, Ian Lance Taylor notifications@github.com
wrote:

@jasonpfox https://github.com/jasonpfox There is no point to having a
discussion on a closed issue. See https://golang.org/wiki/Questions .


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#151 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AQY2pk_mDGwW-351-5MST6WlrDdeIuhxks5qMEMtgaJpZM4I2oXm
.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 15, 2016

@jasonpfox Take it to a forum, as described in the link above.

But the issue will not get reopened, because changing anything in this area would break the Go 1 guarantee (https://golang.org/doc/go1compat.html).

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 15, 2016

See also the discussion in: #12711

@golang golang locked and limited conversation to collaborators Jun 15, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.