What's the maximum array length?

[eric...@arm.com]

The spec says that " The length is part of the array's type; it must evaluate to a non-negative constant representable by a value of type int. ", so on a 64-bit environment, I assume that the maximum array length should be math.MaxInt64, am I right ? But the following code doesn't compile:

    package main

    var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}

[Rob Pike]

For those watching at home, the error message is

compile: data too large

-rob

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e295dd1c-2abd-4709-a6c4-1252ef635b5en%40googlegroups.com.

[Rob Pike]

Ah, and here's why. cmd/internal/obj/objfile as a 32-bit data size.

if int64(uint32(dataOff)) != dataOff {

log.Fatalf("data too large")

}

[Kurtis Rader]

On Thu, Oct 27, 2022 at 9:16 PM Rob Pike <r...@golang.org> wrote:

For those watching at home, the error message is

compile: data too large

Yes, but as I noted in my reply if you remove the composite literal initializer (i.e., reducing it to just var x = [1 << 34]byte{}) I get this error (using Go 1.19 on macOS):

./x.go:3:5: main.x: symbol too large (17179869184 bytes > 2000000000 bytes)

That appears to be the primary limit. That including a composite literal initializer that exceeds that limit, causing a more ambiguous error, seems like a related, but secondary, issue.

 

On Fri, Oct 28, 2022 at 12:43 PM eric...@arm.com <eric...@arm.com> wrote:

The spec says that " The length is part of the array's type; it must evaluate to a non-negative constant representable by a value of type int. ", so on a 64-bit environment, I assume that the maximum array length should be math.MaxInt64, am I right ? But the following code doesn't compile:

    package main

    var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[tapi...@gmail.com]

The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid,

though the practical size of non-zero-size array is hard limited in some way.

[T L]

On Sat, Oct 29, 2022 at 12:11 PM Kurtis Rader <kra...@skepticism.us> wrote:

Did you not see my reply pointing out the same thing? That is, given a particular platform and executable format the limit is likely to be much less than math.MaxInt. Alternatively, was my reply not clear about the practical versus theoretical limit of the size of an array? Which is not to say that your reply is invalid. I'm just curious how you view your reply as being more clear than mine. :-)

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com.

[Axel Wagner]

You might want to check out the order of messages as seen by google groups: https://groups.google.com/g/golang-nuts/c/mw5f2kyEjpA

Either your Message was delivered to groups delayed, or Kurtis message was delivered delayed to you.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAHbs%3DNbmgsUet1GW4AbbBeOQ9xeUZd92ybb28L-m1O8-Ze3CtQ%40mail.gmail.com.

[tapi...@gmail.com]

On Saturday, October 29, 2022 at 3:52:16 PM UTC+8 axel.wa...@googlemail.com wrote:

You might want to check out the order of messages as seen by google groups: https://groups.google.com/g/golang-nuts/c/mw5f2kyEjpA

Either your Message was delivered to groups delayed, or Kurtis message was delivered delayed to you.

I don't think the order matters at all here. ;)

[eric...@arm.com]

> That appears to be the primary limit. That including a composite literal initializer that exceeds that limit, causing a more ambiguous error, > seems like a related, but secondary, issue.

Yes, this seems to be a related question, see https://github.com/golang/go/issues/9862. If we do not allow static data larger than 2G, then the description of the array in the spec may need to be slightly modified?

[Ian Lance Taylor]

On Sun, Oct 30, 2022, 6:38 PM eric...@arm.com <eric...@arm.com> wrote:

> That appears to be the primary limit. That including a composite literal initializer that exceeds that limit, causing a more ambiguous error, > seems like a related, but secondary, issue.

Yes, this seems to be a related question, see https://github.com/golang/go/issues/9862. If we do not allow static data larger than 2G, then the description of the array in the spec may need to be slightly modified?

That would be an implementation restriction for a particular implementation, not a language change.  We could add it to the spec.  Though I think it's reasonably clear that no implementation will be able to support a very large array even if the language permits it, and that the precise definition of "very large" is implementation dependent.

Ian

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/624b7b28-b750-40a0-9407-d3fe16d1f956n%40googlegroups.com.