miscellaneous array questions...

Simen Kjærås simen.kjaras at gmail.com
Tue Jul 21 19:20:28 UTC 2020


On Tuesday, 21 July 2020 at 13:42:15 UTC, Steven Schveighoffer 
wrote:
> On 7/21/20 8:34 AM, Adam D. Ruppe wrote:
>
>> The others aren't wrong about stack size limits playing some 
>> role, but the primary reason is that it is a weird hack for 
>> @safe, believe it or not.
> ...
>> I don't recall exactly when this was discussed but it came up 
>> in the earlier days of @safe, I'm pretty sure it worked before 
>> then.
>
> I think this was discussed, but was not the reason for the 
> limitation. The limitation exists even in D1, which is before 
> @safe: https://digitalmars.com/d/1.0/arrays.html#static-arrays
>
> I have stressed before that any access of a pointer to a large 
> object in @safe code should also check that the base of the 
> object is not within the null page (this is not currently 
> done). This is the only way to ensure safety.

It seems the limitation was introduced in DMD 0.123, in May 2005:
https://forum.dlang.org/post/d61jpa$1m0l$1@digitaldaemon.com
Walter gives some justification in the post immediately following:

> 1) Gigantic static arrays are often either the result of a typo 
> or are a
> newbie mistake.
> 2) Such require a lot of memory for the compiler to handle. 
> Before the OS
> officially runs out of memory, it goes to greater and greater 
> lengths to
> scavenge memory for the compiler, often bringing the computer 
> to its knees
> in desperation.
> 3) D needs to be a portable language, and by capping the array 
> size a
> program is more likely to be portable.
> 4) Giant arrays are reflected in a corresponding giant size for 
> the exe
> file.
> 5) There simply isn't a need I can think of for such arrays. 
> There shouldn't
> be a problem with allocating them dynamically.

I admit I thought it was an old optlink limitation, but it seems 
it's basically arbitrary.

--
   Simen


More information about the Digitalmars-d-learn mailing list