Navigation Menu

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

cmd/gc: int should be 64 bits wide on 64-bit platforms #2188

Closed
gopherbot opened this issue Aug 26, 2011 · 18 comments
Closed

cmd/gc: int should be 64 bits wide on 64-bit platforms #2188

gopherbot opened this issue Aug 26, 2011 · 18 comments
Milestone

Comments

@gopherbot
Copy link

by webmaster@webmaster.ms:

Number of arrays items are limited to 2^31 even on 64 bit platforms

testcase:
============================
package main

func main() {
  a := make([]int32, 2*1000*1000*1000) // 8Gb alloc, ok
  println(len(a))

  b := make([]int8, 3*1000*1000*1000) // 3Gb alloc, failed
  println(len(b))
}
============================
@adg
Copy link
Contributor

adg commented Aug 26, 2011

Comment 1:

This is a known issue. It will happen at some point.

Status changed to LongTerm.

@adg
Copy link
Contributor

adg commented Aug 26, 2011

@adg
Copy link
Contributor

adg commented Aug 26, 2011

@gopherbot
Copy link
Author

Comment 4 by jp@webmaster.ms:

I did not mean to make int longer.
Somebody changed the subject line.
I talked about arrays only.
Currently, make() and [] accept ANY integral type without explicit conversion to int:
  a := make([]int32, byte(2))
  println(a[byte(1)])
Can they deal appropriately with integrals longer than int (uint32,int64,uint64) ?
  a := make([]int8, uint64(1<<32+2))
  println(a[uint64(1<<32)])

@rsc
Copy link
Contributor

rsc commented Aug 28, 2011

Comment 5:

len(x) is an int.
If you want to be able to create arrays with
more than 1<<31 - 1 elements, then int
has to be wider.

@gopherbot
Copy link
Author

Comment 6 by webmaster@webmaster.ms:

len() can have a "fuzzy" integral type, similar to parameter of make()
In "len(a) + int(1)" it is int.
In "len(a) < byte(1)" it is byte.
In "println(len(a))" or "x := len(a)" it is uintptr.
It is also similar to the type of numeric constant (they can be used as any integral
type without explicit conversion) but with defaulting to uintptr instead of int.

@gopherbot
Copy link
Author

Comment 7 by webmaster@webmaster.ms:

I understand from the maillist, you insist on len() to be int only to have ability to
write "for i:=0; i<len(x); i++".
This will be possible.
As well as "for i:=uint64(0); i<len(x); i++" for long arrays.

@gopherbot
Copy link
Author

Comment 8 by webmaster@webmaster.ms:

I understand from the maillist, you insist on len() to be int only to have ability to
write "for i:=0; i<len(x); i++".
This will be possible.
As well as "for i:=uint64(0); i<len(x); i++" for long arrays.
But this will fail (size is uintptr, i is int:
size:=len(x)
for i:=0; i<size; i++

@rsc
Copy link
Contributor

rsc commented Aug 29, 2011

Comment 9:

Discussing language changes in the issue tracker
is not particularly productive.  If you'd like to continue
this conversation please reply to that thread in
golang-nuts.  But please also read it first.
The problem with a fuzzy len is that if you write
for i := 0; i < len(x); i++ {
and i has type int but len(x) is some fuzzy number
that is bigger than any possible int, then the loop
will be wrong: it will wrap around and die using i
as a (negative) loop index.

@adg
Copy link
Contributor

adg commented Aug 29, 2011

Comment 10:

The simple fix is to widen int, and that's what we plan to do.
I changed the issue title as we didn't already have an entry for tracking this issue.

@rsc
Copy link
Contributor

rsc commented Dec 9, 2011

Comment 11:

Labels changed: added priority-later.

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 13:

Labels changed: added go1.1.

@rsc
Copy link
Contributor

rsc commented Sep 14, 2012

Comment 14:

This is a compiler (and runtime) change, not a spec change.

@rsc
Copy link
Contributor

rsc commented Sep 24, 2012

Comment 15:

Status changed to Started.

@rsc
Copy link
Contributor

rsc commented Sep 24, 2012

Comment 16:

There have been lots of recent relevant commits. hg log -k 'Update issue #2188' :-(

@remyoudompheng
Copy link
Contributor

Comment 17:

What is the use of "update issue #2188" if they don't show up here?

@fsouza
Copy link
Contributor

fsouza commented Sep 24, 2012

Comment 18:

It used to work.

@rsc
Copy link
Contributor

rsc commented Sep 25, 2012

Comment 19:

This issue was closed by revision 10ea651.

Status changed to Fixed.

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 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
Development

No branches or pull requests

5 participants