I'm not going to go into the intricacies of how the above comments differ from why this implemention really won't crash on the more common OSs, but I will say (not having looked at the code given it isn't on the linked page right now) that there definitely are cases where a crash could result due to his supposed buffer overflow -- albeit not at the actual time of the overflow.
If for instance you had a struct { long valueArray[65535]; long *valuePtr; } and then attempted to write into valueArray[65535], you would likely be writing into valuePtr, thus leading to a crash at a later point when it tries to derefence it. Even malloc debugging tools would not catch this particular error in action, but that's why gdb has watch points!
Oh yeah, and LP64 and ILP64 systems have 8 byte sized longs which goes against the "allocate in 8 byte units" assumption for why it doesn't crash (it tends to allocate ALIGNED to 8 bytes on some systems, and 16 on others, due to vector programming reasons).
But.... It doesn't matter if a simulation is only simulating things that are x small and y big. When we actually know that we are seeing x and y, we will think that they are the biggest and smallest things in existence.
We wouldn't be able to derive that we are actually within a simulation. We might also prove that our world can be digitally represented, but that does not infer that this is in fact a computer simulation.
As for trying to go beyond the limits of space, the number of atoms that need to be simulated remains constant... Maybe precision loss would be an issue, but given our life times and the imposed speed of light, it seems that one could give a provable upper limit that is within the limits of the simulations precision.
It's fun to think of our world as a computer simulation, and the speed of light simply being the amount of time it takes to transfer data amongs threads, or some other similar concept!;-)
Slashdot Mirror
I'm not going to go into the intricacies of how the above comments differ from why this implemention really won't crash on the more common OSs, but I will say (not having looked at the code given it isn't on the linked page right now) that there definitely are cases where a crash could result due to his supposed buffer overflow -- albeit not at the actual time of the overflow.
If for instance you had a struct { long valueArray[65535]; long *valuePtr; } and then attempted to write into valueArray[65535], you would likely be writing into valuePtr, thus leading to a crash at a later point when it tries to derefence it. Even malloc debugging tools would not catch this particular error in action, but that's why gdb has watch points!
Oh yeah, and LP64 and ILP64 systems have 8 byte sized longs which goes against the "allocate in 8 byte units" assumption for why it doesn't crash (it tends to allocate ALIGNED to 8 bytes on some systems, and 16 on others, due to vector programming reasons).
We wouldn't be able to derive that we are actually within a simulation. We might also prove that our world can be digitally represented, but that does not infer that this is in fact a computer simulation.
As for trying to go beyond the limits of space, the number of atoms that need to be simulated remains constant... Maybe precision loss would be an issue, but given our life times and the imposed speed of light, it seems that one could give a provable upper limit that is within the limits of the simulations precision. It's fun to think of our world as a computer simulation, and the speed of light simply being the amount of time it takes to transfer data amongs threads, or some other similar concept! ;-)