On Mon, Nov 24, 2008 at 2:01 PM, Andreas Klein <klein@cage.ugent.be> wrote:
Dear developers.
I send this both to the boost and the gcc developers.
I have found a strange limitation for the size of an array. The error is the same both for boost 1.36 and for the array in gcc 4.3.2 (and in the gcc 4.4 snapshot I use). I am almost sure that it is a bug of gcc and not of the array implementation.
Here is the code.
#include<array> using namespace std;
int main () { array<unsigned int, (1<<22)> a; // Create a big array
a[(1<<22)-13]=0; // This give a segmantation fault }
There is no bug. boost::array does no dynamic memory allocation, so you are creating a circa 30 MB array on the stack. This is enough to blow the stack size limit on most OSs.
In contrast a C-array works fine.
int main () { unsigned int a[1<<22];
a[(1<<22)-13]=0; }
Since the naturale implementation of the array class is just a wrapper around the C-style array this is very strange.
Sheer luck probably. You have gone beyond an implementation defined limit and it is UB. In fact using a C -style array might (or not) have blown the stack in the same way.
I tryed to track down the bug. You use the following implementation:
[ Sniped: code using new instead of a member array ]
It seams that this resolves the bug.
But you lose some nice properties of boost::array: no dynamic allocation and aggregate initialization. At this point you might as well use std::vector.
But I can not explain why. I tested the code with the intel compiler and it works fine for both implementations. So it seams that it is a gcc bug, that the first solution do not work. What happens here?
It is not a bug of gcc (although a warning would have been appreciated), just a manifestation of UB. It might be that the intel compiler sets the stack size limit higher, it disables stack overflow checking or simply you are just being lucky (or unlucky, depends on how you see it) and UB is not showing up as an hard crash. Morale: do not stack allocate huge objects. -- gpd