Bug 2819 – array.sort segfaults if array length >=0x8F_FFFF
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2009-04-07T13:17:00Z
Last change time
2014-04-18T09:14:23Z
Keywords
wrong-code
Assigned to
nobody
Creator
clugdbug
Comments
Comment #0 by clugdbug — 2009-04-07T13:17:33Z
void main() {
auto a = new uint[0x8F_FFFF]; // smallest size that fails
a.sort;
}
It's caused by the hard-coded
byte*[40] stack; // stack
in
extern (C) long _adSort(Array a, TypeInfo ti)
in qsort.d.
Affects both D1 and D2.
This is just another reason for the built-in .sort to be deprecated.
Comment #1 by smjg — 2009-04-07T14:20:12Z
(In reply to comment #0)
> This is just another reason for the built-in .sort to be deprecated.
I don't understand. How is this bug a consequence of sort being built in?
Comment #2 by clugdbug — 2009-04-07T14:47:23Z
(In reply to comment #1)
> (In reply to comment #0)
> > This is just another reason for the built-in .sort to be deprecated.
>
> I don't understand. How is this bug a consequence of sort being built in?
It isn't. But the fact that the built-in sort is buggy as well as slow and limited, further weakens its appeal. It just doesn't seem to have much going for it.
Comment #3 by andrei — 2009-04-07T15:05:46Z
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > This is just another reason for the built-in .sort to be deprecated.
> >
> > I don't understand. How is this bug a consequence of sort being built in?
>
> It isn't. But the fact that the built-in sort is buggy as well as slow and
> limited, further weakens its appeal. It just doesn't seem to have much going
> for it.
>
I agree. By the way, if anyone has run numbers on the relative speeds of various sort implementations, please share.
Comment #4 by matti.niemenmaa+dbugzilla — 2009-04-07T15:17:15Z