in reply to Re: Really slow sort, but useful.
in thread Really slow sort, but useful.

I bow to your (and theorbtwo's) longer association with Perl. I wasn't exactly challenging theorbtwo's statement, just questioning how/why it would occur.

I still have a problem conceiving of the circumstance that would cause the segfault though? Obviously the effect of your choices is retained, but at any given point, the sort algorithm ony has the state of the stack and two values to consider. I can see how the result could be a non-useful outcome of the sort, but can't see what would cause the segfault.

I remember the recent thread where someone was using rand within sort to effect a shuffle. I assume that in pre-5.6 perls this would also have caused a problem? Though I don't recall mention of it at the time.

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

Replies are listed 'Best First'.
Re: Really slow sort, but useful.
by Abigail-II (Bishop) on Nov 29, 2002 at 11:08 UTC
    Internally, in the C library, the qsort routine is working with pointers, and lots of them. You may think all the world is a stack, but in reality, it isn't. It's C, it's pointers, and the comparison function is assumed to behave. Of course you'll run the risk of following a pointer to no-no land if the function doesn't behave. C isn't Perl.

    Abigail

[reply]
[d/l]

      It would behoove you not to make assumptions.

      I implemented my first quicksort algorithm using the DECUS integer C compiler circa 1985. I'm familiar with the algorithm. Though I admit my implementation was crude and slow by comparison with modern ones.

      Even using the non-recursive, "collapse the walls" implementations, the pointers still reside on the stack much as they always did. So stack is involved.

      Barring that the comparison function actually corrupted the pointers it is passed, which ought not be possible given proper use of const, I fail to see how returning inconsistant results (-1,0,1) would cause the algorithm to following a bad pointer. It supplies the pointers to the comparison function and swaps as required.

      Where is the scope for the pointers to become corrupt?

      That was the question I was, and still am asking. I'm not saying it cannot be true, I just can't see how it occurs, but would like to understand.

      Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
      Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
      Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
      Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[reply]

In Section Cool Uses for Perl