HI all,
> Does anyone know what the upper bound on this could be?
Interesting question. I have a thought experiment theory: "LIMIT_MAX =
(TOTAL_MEMORY - OTHER_SERVICES - DATA) / MBIT"
Explanation:
1. Assuming you're using 64-bit OS and memory structure is aligned using
64-bit memory, your MBIT should be `uint64` for each memory address as a
value.
2. Each level of pointer (e.g. pointer of pointer ) shall only consume 1
`uint64` memory space.
3. Iterate the thinking recursively and you eventually ran out of memory
available on a given system.
4. Hence, the upper limit, LIMIT_MAX shall be the remaining free memory
after subtracting other services consuming the memory space
(OTHER_SERVICES) and the initial data size, the value of the first degree
pointer (DATA).
Note:
1. For 32-bit memory addressing, it's at max 4GB at `uint32` per iteration
due to the addressing capacity limit, which is why 64-bit CPU is created at
the first place.
----
I may be wrong but I'm curious to know. As for how to prove it, I have no
idea and I don't intend to crash my laptop at the moment. Besides, I never
use pointer of pointer beyond 3 degree deep. =p
Regards,
Holloway
On Thursday, March 10, 2022 at 2:53:05 PM UTC+8 kortschak wrote:
> On Wed, 2022-03-09 at 18:58 -0800, shan...@gmail.com wrote:
> > This morning someone asked about dereferincing a pointer to a pointer
> > to a pointer
> >
> > At first nobody had ever thought about, let alone knew the answer,
> > but some example code was shown, and sure enough ***val is possible
> > ```
> > package main
> >
> > import "fmt"
> >
> > func main() {
> > a := 0
> > b := &a
> > c := &b
> > UltimatePointOne(&c)
> > fmt.Println(a)
> > }
> >
> > func UltimatePointOne(n ***int) {
> > ***n = 1
> > }
> > ```
> >
> >
> > On a lark a go playground example was tried to find what the maximum
> > * is in Go
> >
> > https://go.dev/play/p/YhibY3p7TSD
> >
> > There's 28 there, but it's not the limit
> >
> > Does anyone know what the upper bound on this could be?
> >
> > 256 * ?
> >
> > 32k * ?
>
> I think aspects of this thread are sad. None of us know the background
> of the OP and this kind of thinking illustrates a joyful level of
> curiosity that could have been answered in a way that helps the
> questioner and build a positive community (for Shane, Rob did answer it
> and in way that is really quite deep, and thinking about how he
> answered it will teach you something that is worth learning).
>
> Calling a question "silly" demeans the questioner without understanding
> where they are coming from.
>
> Dan
>
>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/50570864-f5f2-4835-b22b-6852bfb49949n%40googlegroups.com.
