SORTf_DESC

--001a113d51689e4fc20554722ae9
Content-Type: text/plain; charset="UTF-8"

When the SORTf_DESC flag is on in pp_sort.c (I guess this flag is turned on
by some higher level perl code... it's not mentioned in "perldoc sort"),
the original comparison function, which will have been squirreled away in
PL_sort_RealCmp, is replaced by

static I32
cmp_desc(pTHX_ gptr const a, gptr const b)
{
    return -PL_sort_RealCmp(aTHX_ a, b);
}


According to "perldoc -f sort", a user-supplied comparison must return

an integer less than, equal to, or greater than 0, depending on how the
elements of the list are to be ordered. (The "<=>" and "cmp" operators are
extremely useful in such routines.)


I am troubled by two things. One is that with 64 bit integers becoming
increasingly common, returning any integer that doesn't fit in an I32 is
likely to raise havoc. I guess this can be fixed by changing "perldoc -f"
to insist that the integer returned be "a 32-bit signed integer". A more
subtle concern is that the maximum negative 32-bit signed integer has no
positive counterpart, so negating it doesn't change the sign. More
documentation changes to "perldoc -f"?

For what it's worth, as I chug along on destabilizing mergesort, I have
found it useful to "normalize" what is returned by the comparison so it
returns only -1, 0 and 1 (just -1 and 1 when a stable sort is demanded). So
I could (although I don't...yet) use the return value to index into an
array of size 3. And I can determine "compatibility of merging adjacent
runs with senses s1 and s2, respectively" with

if (s1*s2 >= 0) { /* candidate for merging */ }


I wouldn't dare take the product of two arbitrary integers without worrying
about overflow, but -1, 0 and 1 are well behaved. This relatively simple
test swallows up a lot of special cases. The only failure case is where s1
and and s2 are both non-zero with opposite signs, indicating one run is
strictly increasing and the other strictly decreasing, so there is no hope
of "bridging them together to form a single run".

--001a113d51689e4fc20554722ae9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">When the SORTf_DESC flag is on in pp_sort.c (I guess this =
flag is turned on by some higher level perl code... it&#39;s not mentioned =
in &quot;perldoc=C2=A0sort&quot;), the original comparison function, which =
will have been squirreled away in PL_sort_RealCmp, is replaced by<div><div>=
<br></div></div><blockquote style=3D"margin:0px 0px 0px 40px;border:none;pa=
dding:0px"><div><div><div>static I32</div></div></div><div><div><div>cmp_de=
sc(pTHX_ gptr const a, gptr const b)</div></div></div><div><div><div>{</div=
></div></div><div><div><div>=C2=A0 =C2=A0 return -PL_sort_RealCmp(aTHX_ a, =
b);</div></div></div><div><div><div>}</div></div></div></blockquote><div><d=
iv><br></div></div><div>According to &quot;perldoc -f sort&quot;, a user-su=
pplied comparison must return</div><div><br></div><blockquote style=3D"marg=
in:0px 0px 0px 40px;border:none;padding:0px"><div><div>an integer less than=
, equal to, or greater than 0, depending on how the elements of the list ar=
e to be ordered. (The &quot;&lt;=3D&gt;&quot; and &quot;cmp&quot; operators=
 are extremely useful in such routines.)</div></div></blockquote><br><div>I=
 am troubled by two things. One is that with 64 bit integers becoming incre=
asingly common, returning any integer that doesn&#39;t fit in an I32 is lik=
ely to raise havoc. I guess this can be fixed by changing &quot;perldoc -f&=
quot; to insist that the integer returned be &quot;a 32-bit signed integer&=
quot;. A more subtle concern is that the maximum negative 32-bit signed int=
eger has no positive counterpart, so negating it doesn&#39;t change the sig=
n. More documentation changes to &quot;perldoc -f&quot;?</div><div><br></di=
v><div>For what it&#39;s worth, as I chug along on destabilizing mergesort,=
 I have found it useful to &quot;normalize&quot; what is returned by the co=
mparison so it returns only -1, 0 and 1 (just -1 and 1 when a stable sort i=
s demanded). So I could (although I don&#39;t...yet) use the return value t=
o index into an array of size 3. And I can determine &quot;compatibility of=
 merging adjacent runs with senses s1 and s2, respectively&quot; with</div>=
<div><br></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0=
px"><div>if (s1*s2 &gt;=3D 0) { /* candidate for merging */ }</div></blockq=
uote><div><br></div><div>I wouldn&#39;t dare take the product of two arbitr=
ary integers without worrying about overflow, but -1, 0 and 1 are well beha=
ved. This relatively simple test swallows up a lot of special cases. The on=
ly failure case is where s1 and and s2 are both non-zero with opposite sign=
s, indicating one run is strictly increasing and the other strictly decreas=
ing, so there is no hope of &quot;bridging them together to form a single r=
un&quot;.</div></div>

--001a113d51689e4fc20554722ae9--
0
jpl
7/16/2017 4:56:41 PM
perl.perl5.porters 46539 articles. 0 followers. Follow

6 Replies
37 Views

Similar Articles

[PageSpeed] 11

John P. Linderman wrote:
> When the SORTf_DESC flag is on in pp_sort.c (I guess this flag is =
turned on
> by some higher level perl code... it's not mentioned in "perldoc =
sort"),

It is set by pp_sort (in pp_sort.c) iff the op itself has the =
OPpSORT_DESCEND flag set.  That flag gets set in op.c for code like =
=91sort { $b <=3D> $a } ...=92.

> the original comparison function, which will have been squirreled away =
in
> PL_sort_RealCmp, is replaced by
>=20
> static I32
> cmp_desc(pTHX_ gptr const a, gptr const b)
> {
>     return -PL_sort_RealCmp(aTHX_ a, b);
> }
>=20
>=20
> According to "perldoc -f sort", a user-supplied comparison must return
>=20
> an integer less than, equal to, or greater than 0, depending on how =
the
> elements of the list are to be ordered. (The "<=3D>" and "cmp" =
operators are
> extremely useful in such routines.)
>=20
>=20
> I am troubled by two things. One is that with 64 bit integers becoming
> increasingly common, returning any integer that doesn't fit in an I32 =
is
> likely to raise havoc.

Yes, indeed.

> I guess this can be fixed by changing "perldoc -f"
> to insist that the integer returned be "a 32-bit signed integer".

I hope not.

> A more
> subtle concern is that the maximum negative 32-bit signed integer has =
no
> positive counterpart, so negating it doesn't change the sign. More
> documentation changes to "perldoc -f"?

Isn=92t this also a concern with 64-bit integers?

>=20
> For what it's worth, as I chug along on destabilizing mergesort, I =
have
> found it useful to "normalize" what is returned by the comparison so =
it
> returns only -1, 0 and 1 (just -1 and 1 when a stable sort is =
demanded).=20

That sounds like a good idea.
0
sprout
7/23/2017 9:01:05 PM
--001a114093fa9637f70555102e30
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos <sprout@cpan.org>
wrote:

> John P. Linderman wrote:
> > When the SORTf_DESC flag is on in pp_sort.c (I guess this flag is turne=
d
> on
> > by some higher level perl code... it's not mentioned in "perldoc sort")=
,
>
> It is set by pp_sort (in pp_sort.c) iff the op itself has the
> OPpSORT_DESCEND flag set.  That flag gets set in op.c for code like =E2=
=80=98sort {
> $b <=3D> $a } ...=E2=80=99.
>

I have a test script that does

my Compares;
sub countcmp {
    my ($a,$b) =3D @_;
    ++Compares;
    $a <=3D> $b;
}
....
Compares=3D0;
@results =3D sort { countcmp($b,$a) } @inputs;


so I can use the number of comparisons done as a measure of performance. Is
op.c "smart enough" to set OPpSORT_DESCEND in the final line?
If not, is there a problem with supporting a "reverse" subpragma in sort.pm
to force it on?

> the original comparison function, which will have been squirreled away in
> > PL_sort_RealCmp, is replaced by
> >
> > static I32
> > cmp_desc(pTHX_ gptr const a, gptr const b)
> > {
> >     return -PL_sort_RealCmp(aTHX_ a, b);
> > }
> >
> >
> > According to "perldoc -f sort", a user-supplied comparison must return
> >
> > an integer less than, equal to, or greater than 0, depending on how the
> > elements of the list are to be ordered. (The "<=3D>" and "cmp" operator=
s
> are
> > extremely useful in such routines.)
> >
> >
> > I am troubled by two things. One is that with 64 bit integers becoming
> > increasingly common, returning any integer that doesn't fit in an I32 i=
s
> > likely to raise havoc.
>
> Yes, indeed.
>
> > I guess this can be fixed by changing "perldoc -f"
> > to insist that the integer returned be "a 32-bit signed integer".
>
> I hope not.
>
> > A more
> > subtle concern is that the maximum negative 32-bit signed integer has n=
o
> > positive counterpart, so negating it doesn't change the sign. More
> > documentation changes to "perldoc -f"?
>
> Isn=E2=80=99t this also a concern with 64-bit integers?
>

Yes. But it is far above my paygrade to find all the sort-related I32's and
replace them with IV's,
although that would be a wonderful thing.

>
> > For what it's worth, as I chug along on destabilizing mergesort, I have
> > found it useful to "normalize" what is returned by the comparison so it
> > returns only -1, 0 and 1 (just -1 and 1 when a stable sort is demanded)=
..
>
> That sounds like a good idea.
>
>

--001a114093fa9637f70555102e30
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos <span dir=3D"ltr">&lt;=
<a href=3D"mailto:sprout@cpan.org" target=3D"_blank">sprout@cpan.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">John P=
.. Linderman wrote:<br>
&gt; When the SORTf_DESC flag is on in pp_sort.c (I guess this flag is turn=
ed on<br>
&gt; by some higher level perl code... it&#39;s not mentioned in &quot;perl=
doc sort&quot;),<br>
<br>
It is set by pp_sort (in pp_sort.c) iff the op itself has the OPpSORT_DESCE=
ND flag set.=C2=A0 That flag gets set in op.c for code like =E2=80=98sort {=
 $b &lt;=3D&gt; $a } ...=E2=80=99.<br></blockquote><div><br></div><div>I ha=
ve a test script that does</div><div><br></div></div></div><blockquote styl=
e=3D"margin:0px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div>my Compares;</div></div></div><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div>sub countcmp {</div></d=
iv></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0 =
=C2=A0 my ($a,$b) =3D @_;</div></div></div><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div>=C2=A0 =C2=A0 ++Compares;</div></div></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0 =C2=A0 $a &lt;=
=3D&gt; $b;</div></div></div><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><div>}</div></div></div><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div>...</div></div></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>Compares=3D0;</div></div></div><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div>@results =3D sort { countcmp($b,$a) } =
@inputs;</div></div></div></blockquote><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><div><br></div><div>so I can use the number of comparison=
s done as a measure of performance. Is op.c &quot;smart enough&quot; to set=
 OPpSORT_DESCEND in the final line?</div><div>If not, is there a problem wi=
th supporting a &quot;reverse&quot; subpragma in <a href=3D"http://sort.pm"=
>sort.pm</a> to force it on?</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
&gt; the original comparison function, which will have been squirreled away=
 in<br>
&gt; PL_sort_RealCmp, is replaced by<br>
&gt;<br>
&gt; static I32<br>
&gt; cmp_desc(pTHX_ gptr const a, gptr const b)<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 =C2=A0return -PL_sort_RealCmp(aTHX_ a, b);<br>
&gt; }<br>
&gt;<br>
&gt;<br>
&gt; According to &quot;perldoc -f sort&quot;, a user-supplied comparison m=
ust return<br>
&gt;<br>
&gt; an integer less than, equal to, or greater than 0, depending on how th=
e<br>
&gt; elements of the list are to be ordered. (The &quot;&lt;=3D&gt;&quot; a=
nd &quot;cmp&quot; operators are<br>
&gt; extremely useful in such routines.)<br>
&gt;<br>
&gt;<br>
&gt; I am troubled by two things. One is that with 64 bit integers becoming=
<br>
&gt; increasingly common, returning any integer that doesn&#39;t fit in an =
I32 is<br>
&gt; likely to raise havoc.<br>
<br>
Yes, indeed.<br>
<br>
&gt; I guess this can be fixed by changing &quot;perldoc -f&quot;<br>
&gt; to insist that the integer returned be &quot;a 32-bit signed integer&q=
uot;.<br>
<br>
I hope not.<br>
<br>
&gt; A more<br>
&gt; subtle concern is that the maximum negative 32-bit signed integer has =
no<br>
&gt; positive counterpart, so negating it doesn&#39;t change the sign. More=
<br>
&gt; documentation changes to &quot;perldoc -f&quot;?<br>
<br>
Isn=E2=80=99t this also a concern with 64-bit integers?<br></blockquote><di=
v><br></div><div>Yes. But it is far above my paygrade to find all the sort-=
related I32&#39;s and replace them with IV&#39;s,</div><div>although that w=
ould be a wonderful thing.</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
&gt;<br>
&gt; For what it&#39;s worth, as I chug along on destabilizing mergesort, I=
 have<br>
&gt; found it useful to &quot;normalize&quot; what is returned by the compa=
rison so it<br>
&gt; returns only -1, 0 and 1 (just -1 and 1 when a stable sort is demanded=
).<br>
<br>
That sounds like a good idea.<br>
<br>
</blockquote></div><br></div></div>

--001a114093fa9637f70555102e30--
0
jpl
7/24/2017 1:27:52 PM
John P. Linderman wrote:
>I have a test script that does
>
>my Compares;

No you don't.  Not one that you've run, at least.

>@results = sort { countcmp($b,$a) } @inputs;
....
>Is op.c "smart enough" to set OPpSORT_DESCEND in the final line?

No, and it wouldn't help if it did.  countcmp($a, $b) isn't optimised
into anything special, so countcmp($b, $a) isn't any more expensive.

>If not, is there a problem with supporting a "reverse" subpragma in sort.pm
>to force it on?

Eww, action at a distance.  Lexical scoping would make it not a total
disaster, but inverting the sense of all sort operations doesn't seem
like a useful kind of language tweak to make by pragma.

-zefram
0
zefram
7/24/2017 1:39:11 PM
--001a11c033d6c618ed0555235cb7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 24, 2017 at 9:27 AM, John P. Linderman <jpl.jpl@gmail.com>
wrote:

>
> On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos <sprout@cpan.org>
> wrote:
>
>> ...
>
> > I guess this can be fixed by changing "perldoc -f"
>> > to insist that the integer returned be "a 32-bit signed integer".
>>
>> I hope not.
>>
>> > A more
>> > subtle concern is that the maximum negative 32-bit signed integer has =
no
>> > positive counterpart, so negating it doesn't change the sign. More
>> > documentation changes to "perldoc -f"?
>>
>> Isn=E2=80=99t this also a concern with 64-bit integers?
>>
>
Is there already a typedef for "that which comparison routines return"? If
so, I will use it in pp_sort.c instead of the I32's that I can identify as
that. If not, I will create a typedef for that within pp_sort.c, to make it
as easy as possible to stop assuming compares return I32's. Something like

typedef SVCOMPARE_RET_t I32;

>
>

--001a11c033d6c618ed0555235cb7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Jul 24, 2017 at 9:27 AM, John P. Linderman <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jpl.jpl@gmail.com" target=3D"_blank">jpl.jpl@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
<span class=3D"gmail-">On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:sprout@cpan.org" target=3D"_blank"=
>sprout@cpan.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">...</blockquote></span></div></div><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><span class=3D"gmail-"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
&gt; I guess this can be fixed by changing &quot;perldoc -f&quot;<br>
&gt; to insist that the integer returned be &quot;a 32-bit signed integer&q=
uot;.<br>
<br>
I hope not.<br>
<br>
&gt; A more<br>
&gt; subtle concern is that the maximum negative 32-bit signed integer has =
no<br>
&gt; positive counterpart, so negating it doesn&#39;t change the sign. More=
<br>
&gt; documentation changes to &quot;perldoc -f&quot;?<br>
<br>
Isn=E2=80=99t this also a concern with 64-bit integers?<br></blockquote><di=
v></div></span></div></div></div></blockquote><div><br></div><div>Is there =
already a typedef for &quot;that which comparison routines return&quot;? If=
 so, I will use it in pp_sort.c instead of the I32&#39;s that I can identif=
y as that. If not, I will create a typedef for that within pp_sort.c, to ma=
ke it as easy as possible to stop assuming compares return I32&#39;s. Somet=
hing like</div><div><br></div><div>typedef=C2=A0SVCOMPARE_RET_t I32;</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"gmail-"><div>=
=C2=A0<br></div></span></div></div></div></blockquote></div></div></div>

--001a11c033d6c618ed0555235cb7--
0
jpl
7/25/2017 12:20:51 PM
--Apple-Mail=_738EFBB2-E41E-4682-89A8-EF6991FAC378
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jul 25, 2017, at 5:20 AM, "John P. Linderman" <jpl.jpl@gmail.com> =
wrote:

>=20
>=20
> On Mon, Jul 24, 2017 at 9:27 AM, John P. Linderman <jpl.jpl@gmail.com> =
wrote:
>=20
> On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos <sprout@cpan.org> =
wrote:
> ...
> > I guess this can be fixed by changing "perldoc -f"
> > to insist that the integer returned be "a 32-bit signed integer".
>=20
> I hope not.
>=20
> > A more
> > subtle concern is that the maximum negative 32-bit signed integer =
has no
> > positive counterpart, so negating it doesn't change the sign. More
> > documentation changes to "perldoc -f"?
>=20
> Isn=92t this also a concern with 64-bit integers?
>=20
> Is there already a typedef for "that which comparison routines =
return"? If so, I will use it in pp_sort.c instead of the I32's that I =
can identify as that. If not, I will create a typedef for that within =
pp_sort.c, to make it as easy as possible to stop assuming compares =
return I32's. Something like
>=20
> typedef SVCOMPARE_RET_t I32;

I do not believe there is such a typedef.


--Apple-Mail=_738EFBB2-E41E-4682-89A8-EF6991FAC378
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Jul 25, 2017, at 5:20 AM, "John P. Linderman" &lt;<a =
href=3D"mailto:jpl.jpl@gmail.com">jpl.jpl@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Mon, Jul 24, 2017 at 9:27 AM, John P. Linderman =
<span dir=3D"ltr">&lt;<a href=3D"mailto:jpl.jpl@gmail.com" =
target=3D"_blank">jpl.jpl@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span =
class=3D"gmail-">On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos =
<span dir=3D"ltr">&lt;<a href=3D"mailto:sprout@cpan.org" =
target=3D"_blank">sprout@cpan.org</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid =
rgb(204,204,204);padding-left:1ex">...</blockquote></span></div></div><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><span =
class=3D"gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; I guess this can be fixed by changing "perldoc -f"<br>
&gt; to insist that the integer returned be "a 32-bit signed =
integer".<br>
<br>
I hope not.<br>
<br>
&gt; A more<br>
&gt; subtle concern is that the maximum negative 32-bit signed integer =
has no<br>
&gt; positive counterpart, so negating it doesn't change the sign. =
More<br>
&gt; documentation changes to "perldoc -f"?<br>
<br>
Isn=92t this also a concern with 64-bit =
integers?<br></blockquote><div></div></span></div></div></div></blockquote=
><div><br></div><div>Is there already a typedef for "that which =
comparison routines return"? If so, I will use it in pp_sort.c instead =
of the I32's that I can identify as that. If not, I will create a =
typedef for that within pp_sort.c, to make it as easy as possible to =
stop assuming compares return I32's. Something =
like</div><div><br></div><div>typedef&nbsp;SVCOMPARE_RET_t =
I32;</div></div></div></div></blockquote><br></div><div>I do not believe =
there is such a typedef.</div><br></body></html>=

--Apple-Mail=_738EFBB2-E41E-4682-89A8-EF6991FAC378--
0
sprout
7/25/2017 1:16:30 PM
--001a113cc1603b976b0555253574
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Looks as though it may not be necessary. If I read uconfig.h correctly, and
that's not a given, I32 is already a long, where appropriate. So I'll just
continue using it.
Thanks.

On Tue, Jul 25, 2017 at 9:16 AM, Father Chrysostomos <sprout@cpan.org>
wrote:

>
> On Jul 25, 2017, at 5:20 AM, "John P. Linderman" <jpl.jpl@gmail.com>
> wrote:
>
>
>
> On Mon, Jul 24, 2017 at 9:27 AM, John P. Linderman <jpl.jpl@gmail.com>
> wrote:
>
>>
>> On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos <sprout@cpan.org>
>> wrote:
>>
>>> ...
>>
>> > I guess this can be fixed by changing "perldoc -f"
>>> > to insist that the integer returned be "a 32-bit signed integer".
>>>
>>> I hope not.
>>>
>>> > A more
>>> > subtle concern is that the maximum negative 32-bit signed integer has
>>> no
>>> > positive counterpart, so negating it doesn't change the sign. More
>>> > documentation changes to "perldoc -f"?
>>>
>>> Isn=E2=80=99t this also a concern with 64-bit integers?
>>>
>>
> Is there already a typedef for "that which comparison routines return"? I=
f
> so, I will use it in pp_sort.c instead of the I32's that I can identify a=
s
> that. If not, I will create a typedef for that within pp_sort.c, to make =
it
> as easy as possible to stop assuming compares return I32's. Something lik=
e
>
> typedef SVCOMPARE_RET_t I32;
>
>
> I do not believe there is such a typedef.
>
>

--001a113cc1603b976b0555253574
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Looks as though it may not be necessary. If I read=C2=A0uc=
onfig.h correctly, and that&#39;s not a given, I32 is already a long, where=
 appropriate. So I&#39;ll just continue using it.<div>Thanks.</div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jul 25, 201=
7 at 9:16 AM, Father Chrysostomos <span dir=3D"ltr">&lt;<a href=3D"mailto:s=
prout@cpan.org" target=3D"_blank">sprout@cpan.org</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><di=
v class=3D"h5"><br><div><div>On Jul 25, 2017, at 5:20 AM, &quot;John P. Lin=
derman&quot; &lt;<a href=3D"mailto:jpl.jpl@gmail.com" target=3D"_blank">jpl=
..jpl@gmail.com</a>&gt; wrote:</div><br class=3D"m_6044639562694690326Apple-=
interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><br><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 24, 2017 at =
9:27 AM, John P. Linderman <span dir=3D"ltr">&lt;<a href=3D"mailto:jpl.jpl@=
gmail.com" target=3D"_blank">jpl.jpl@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"m_6044639562=
694690326gmail-">On Sun, Jul 23, 2017 at 5:01 PM, Father Chrysostomos <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:sprout@cpan.org" target=3D"_blank">sprou=
t@cpan.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">...</blockquote></span></div></div><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><span class=3D"m_6044639562694690326gmail-"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
&gt; I guess this can be fixed by changing &quot;perldoc -f&quot;<br>
&gt; to insist that the integer returned be &quot;a 32-bit signed integer&q=
uot;.<br>
<br>
I hope not.<br>
<br>
&gt; A more<br>
&gt; subtle concern is that the maximum negative 32-bit signed integer has =
no<br>
&gt; positive counterpart, so negating it doesn&#39;t change the sign. More=
<br>
&gt; documentation changes to &quot;perldoc -f&quot;?<br>
<br>
Isn=E2=80=99t this also a concern with 64-bit integers?<br></blockquote><di=
v></div></span></div></div></div></blockquote><div><br></div><div>Is there =
already a typedef for &quot;that which comparison routines return&quot;? If=
 so, I will use it in pp_sort.c instead of the I32&#39;s that I can identif=
y as that. If not, I will create a typedef for that within pp_sort.c, to ma=
ke it as easy as possible to stop assuming compares return I32&#39;s. Somet=
hing like</div><div><br></div><div>typedef=C2=A0SVCOMPARE_RET_t I32;</div><=
/div></div></div></blockquote><br></div></div></div><div>I do not believe t=
here is such a typedef.</div><br></div></blockquote></div><br></div>

--001a113cc1603b976b0555253574--
0
jpl
7/25/2017 2:32:58 PM
Reply: