develooper Front page | perl.perl5.porters | Postings from August 2017

Changes to pp_sort.c

Thread Next
From:
John P. Linderman
Date:
August 25, 2017 16:07
Subject:
Changes to pp_sort.c
Message ID:
CAC0cEp-NVrNWN6Q+j83D9o+rB7g=h1VGDeRbrS7vqkHwghfVSg@mail.gmail.com
Now that Father C. has committed a change to pp_sort.c to support the
*SORTf_UNSTABLE
*flag, I'm going to start modifying pp_sort.c. But I'd appreciate some
advice about how to do so to make it as easy as possible to adopt the
changes. For example, I realized that I don't need external variable
*PL_sort_RealCmp* to squirrel away the comparison routine that the user
specifies. A static variable in pp_sort.c does just as well, and provides a
cleaner separation of the sort stuff and the perl stuff. And I want to fix
a bug in S_mergesortsv where the stored comparison routine can be
improperly restored, triggering a core dump. These are simple, related
changes, and my inclination is to do a commit to incorporate them. But
perlgit seems to want a single commit for all changes, and there will be
many many more, including some to t/op/sort.t. I can add a test to sort.t
to verify that the segfault no longer happens. Should that be part of a
single commit, involving both sort.t and pp_sort.c, or is it ok to do
separate commits? And should I trickle in simple changes to perlbug, or
wait until I have made all the changes, many of which will be far from
simple?

I think I can do the all-at-once, single commit by just saving current
versions of pp_sort.c and sort.t, cloning a clean version of blead, and
then doing a single commit. But that will lose all the commit commentary on
intermediate commits, which might be useful. I'm happy to do whatever is
preferred, if I know what that is.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About