From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <27721ec6eb1f2bf4019349b1013e6d26@quintile.net> In-Reply-To: <27721ec6eb1f2bf4019349b1013e6d26@quintile.net> From: Charles Forsyth Date: Thu, 25 Jul 2019 12:59:57 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="000000000000cbe3b2058e802a7a" Subject: Re: [9fans] 5c bug Topicbox-Message-UUID: 02d61610-eada-11e9-9d60-3106f5b1d025 --000000000000cbe3b2058e802a7a Content-Type: text/plain; charset="UTF-8" 5c shouldn't discard the cast, which implies a mask, but you should also rewrite the code as you suggest. (it's not just 5c, since it's the same for several other RISCy ones.) On Thu, Jul 25, 2019 at 12:20 PM Steve Simon wrote: > Hi, > > I traced a long standing cifs issue to 5c the compiler. > > The code in lib9p to validate wstat calls > uses a neat bit of casting which fails when using 5c. > > /sys/src/lib9p/srv.c:658-669 > > These following lines missfire reporting type or qid change > when trying to rename files over cifs. > > if((ushort)~r->d.type){ > ... > if((uchar)~r->d.qid.type || .. ){ > > but rewriting them like this makes the code work as expected: > > if(r->d.type != (ushort)~0){ > ... > if(r->d.qid.type != (uchar)~0 || ... ) > > Personally I am happy to hack lib9p but the worry is that > this bug might be affecting other things. > > I have no knowledge of the internals of the compilers so > I am afraid I have made no attempt to dig deeper. > > -Steve > > --000000000000cbe3b2058e802a7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
5c shouldn't discard the cast, which implies a mask, b= ut you should also rewrite the code as you suggest.
(it's not just = 5c, since it's the same for several other RISCy ones.)


On Thu, Jul 25, 2019 at 12:20 PM Steve Simon <steve@quintile.net> wrote:
Hi,

I traced a long standing cifs issue to 5c the compiler.

The code in lib9p to validate wstat calls
uses a neat bit of casting which fails when using 5c.

/sys/src/lib9p/srv.c:658-669

These following lines missfire reporting type or qid change
when trying to rename files over cifs.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if((ushort)~r->d.type){
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if((uchar)~r->d.qid.type || .. ){

but rewriting them like this makes the code work as expected:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(r->d.type !=3D (ushort)~0){
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if(r->d.qid.type !=3D (uchar)~0 || ... )

Personally I am happy to hack lib9p but the worry is that
this bug might be affecting other things.

I have no knowledge of the internals of the compilers so
I am afraid I have made no attempt to dig deeper.

-Steve

--000000000000cbe3b2058e802a7a--