Re: Are there real use cases with the Java access modes?

--===============4023849712599692838==
Content-Type: multipart/alternative; boundary="000000000000338e0105c8138e17"

--000000000000338e0105c8138e17
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Well, you made a statement that the hoist of this kind never happens in C.
It's not true. All I did is found a bizarre example where even worse things
happen.

Alex

On Mon, 26 Jul 2021, 23:27 Gregg Wonderly, <[email protected]> wrote:

>
>
> > On Jul 26, 2021, at 2:06 AM, Alex Otenko via Concurrency-interest <
> [email protected]> wrote:
> >
> > "Don't write the code like that" is what the others said about
> while(!done), so maybe you can see the point they are making.
> >
> > As for this example - please take it as an example of code that may not
> behave as written.
> >
> > As to why it is written like that - well, it is derived from a more
> elaborate mutually recursive case (with a bug).
> >
> > It is perfectly normal to state "zero is even", "x+1 is even, if x is
> odd", and "x+1 is odd, if x is even". This is a recursive definition that
> is derived from a recursive definition of natural numbers. It is not
> complete, but you can't tell if you don't have the compiler that will tel=
l
> you that.
> >
> > So you have:
> >
> > char odd(int x){return even(x-1);}
> > char even(int x){return !x || odd(x-1);}
> >
> > Inline even into odd, do tail call optimization, and you end up with a
> loop like that (ok, x--, not x++). Both of these steps is what modern
> clang, gcc and llvm do
>
> Yes, but this is broken because you can only call even() on evens and
> odd() on odds for it to work.  But the tail recursion resolution on a -O
> compilation never loops and just results in a bogus =E2=80=981=E2=80=99 r=
eturn for all
> cases.  With -g, you get infinite recursion that crashes with a stack
> explosion.  You can debug this and see what=E2=80=99s happening.
>
> I=E2=80=99m still completely focused on the fact that the hoist of the lo=
op
> condition makes the code into an infinite loop that you can=E2=80=99t obs=
erve,
> readily, why a value of done=3Dtrue doesn=E2=80=99t cause the loop to exi=
t.  What you
> can observe in the value of done should cause the loop to exit.  It=E2=80=
=99s
> subtly different in my consideration, but it looks like its a bug because
> you can=E2=80=99t see the code that is executing incorrectly.  With this =
example
> you show, you can put printf in even() and odd(), see the values of x, an=
d
> notice how you end up in odd() with x=3D=3D0 when you call even() with an=
 odd
> value or odd() with an even value and thus the bug occurs.
>
> Gregg Wonderly
>
>
>
>

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

<div dir=3D"auto">Well, you made a statement that the hoist of this kind ne=
ver happens in C. It&#39;s not true. All I did is found a bizarre example w=
here even worse things happen.<div dir=3D"auto"><br></div><div dir=3D"auto"=
>Alex</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Mon, 26 Jul 2021, 23:27 Gregg Wonderly, &lt;<a href=3D"mailto=
:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><br>
<br>
&gt; On Jul 26, 2021, at 2:06 AM, Alex Otenko via Concurrency-interest &lt;=
<a href=3D"mailto:[email protected]" target=3D"_blank" rel=
=3D"noreferrer">[email protected]</a>&gt; wrote:<br>
&gt; <br>
&gt; &quot;Don&#39;t write the code like that&quot; is what the others said=
 about while(!done), so maybe you can see the point they are making.<br>
&gt; <br>
&gt; As for this example - please take it as an example of code that may no=
t behave as written.<br>
&gt; <br>
&gt; As to why it is written like that - well, it is derived from a more el=
aborate mutually recursive case (with a bug).<br>
&gt; <br>
&gt; It is perfectly normal to state &quot;zero is even&quot;, &quot;x+1 is=
 even, if x is odd&quot;, and &quot;x+1 is odd, if x is even&quot;. This is=
 a recursive definition that is derived from a recursive definition of natu=
ral numbers. It is not complete, but you can&#39;t tell if you don&#39;t ha=
ve the compiler that will tell you that.<br>
&gt; <br>
&gt; So you have:<br>
&gt; <br>
&gt; char odd(int x){return even(x-1);}<br>
&gt; char even(int x){return !x || odd(x-1);}<br>
&gt; <br>
&gt; Inline even into odd, do tail call optimization, and you end up with a=
 loop like that (ok, x--, not x++). Both of these steps is what modern clan=
g, gcc and llvm do<br>
<br>
Yes, but this is broken because you can only call even() on evens and odd()=
 on odds for it to work.=C2=A0 But the tail recursion resolution on a -O co=
mpilation never loops and just results in a bogus =E2=80=981=E2=80=99 retur=
n for all cases.=C2=A0 With -g, you get infinite recursion that crashes wit=
h a stack explosion.=C2=A0 You can debug this and see what=E2=80=99s happen=
ing.<br>
<br>
I=E2=80=99m still completely focused on the fact that the hoist of the loop=
 condition makes the code into an infinite loop that you can=E2=80=99t obse=
rve, readily, why a value of done=3Dtrue doesn=E2=80=99t cause the loop to =
exit.=C2=A0 What you can observe in the value of done should cause the loop=
 to exit.=C2=A0 It=E2=80=99s subtly different in my consideration, but it l=
ooks like its a bug because you can=E2=80=99t see the code that is executin=
g incorrectly.=C2=A0 With this example you show, you can put printf in even=
() and odd(), see the values of x, and notice how you end up in odd() with =
x=3D=3D0 when you call even() with an odd value or odd() with an even value=
 and thus the bug occurs.<br>
<br>
Gregg Wonderly<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000338e0105c8138e17--

--===============4023849712599692838==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29uY3VycmVu
Y3ktaW50ZXJlc3QgbWFpbGluZyBsaXN0CkNvbmN1cnJlbmN5LWludGVyZXN0QGNzLm9zd2Vnby5l
ZHUKaHR0cDovL2NzLm9zd2Vnby5lZHUvbWFpbG1hbi9saXN0aW5mby9jb25jdXJyZW5jeS1pbnRl
cmVzdAo=

--===============4023849712599692838==--