On 27 November 2013 21:35, erik quanstrom wrote:
> in the example, don't all the bytes of i correspond to a byte to u,
> and thus can't take on unspecified values?
>
you're right, I was using an overly strict meaning of "correspond"
> actually, even a union won't help you here: "When a value is stored in
> a member of an object of union type, the bytes of the object
> representation that do not correspond to that member but do correspond
> to other members take unspecified values."
in the example, don't all the bytes of i cor
On 27 November 2013 21:18, erik quanstrom wrote:
> the union itself explicitly declares aliasing, not which
> member you use.
>
actually, even a union won't help you here:
"When a value is stored in a member of an object of union type, the bytes
of the object
representation that do not correspon
> I think this is a compiler bug. What happens when you
> declare a union but still do, for example,
>
> (((uchar*)&tmp.i)[0] = ((uchar*)mem)[3]
>
> etc.? I bet it works.
the union itself explicitly declares aliasing, not which
member you use.
- erik
> this code is not correct. it breaks the anti-aliasing rules.
Yep, I see.
Its pretty crufty code, the original had #ifdefs for big and little endian.
I will see if I can push some nicer code fix upstream.
Thanks for the analysis.
-Steve
On Wed, 27 Nov 2013 11:31:26 EST erik quanstrom
wrote:
> On Wed Nov 27 11:04:46 EST 2013, st...@quintile.net wrote:
>
> > Whilst porting some code from the net I came across
> > the attached, rather obscure, code.
> >
> > run as:
> >
> > larch% 8c -D 'STATIC=static' t.c && 8l t.8 && 8.out
the Go to C switch got me :) (no breaks!); couldn't see why more than one
byte was getting the 'x' value! changing buf to "1234" made it more obvious.
On Wed, Nov 27, 2013 at 10:38 AM, erik quanstrom
wrote:
> On Wed Nov 27 13:07:31 EST 2013, skip.tavakkol...@gmail.com wrote:
>
> > why is mips di
On Wed Nov 27 13:07:31 EST 2013, skip.tavakkol...@gmail.com wrote:
> why is mips different (erik's version)?
>
> supermic% ./8.out
> 7878
> mikro% ./v.out
> 7878
> rpi% ./5.out
> 7878
>
because it's big endian. what you're doing there is
putting bytes in specific positions. in this ca
why is mips different (erik's version)?
supermic% ./8.out
7878
mikro% ./v.out
7878
rpi% ./5.out
7878
On Wed, Nov 27, 2013 at 8:31 AM, erik quanstrom wrote:
> On Wed Nov 27 11:04:46 EST 2013, st...@quintile.net wrote:
>
> > Whilst porting some code from the net I came across
> > the att
On Wed Nov 27 11:04:46 EST 2013, st...@quintile.net wrote:
> Whilst porting some code from the net I came across
> the attached, rather obscure, code.
>
> run as:
>
> larch% 8c -D 'STATIC=static' t.c && 8l t.8 && 8.out
> 7878
> larch% 8c -D 'STATIC=' t.c && 8l t.8 && 8.out
Whilst porting some code from the net I came across
the attached, rather obscure, code.
run as:
larch% 8c -D 'STATIC=static' t.c && 8l t.8 && 8.out
7878
larch% 8c -D 'STATIC=' t.c && 8l t.8 && 8.out
0
I think it is tickling a bug in 8c, though
I may be just sh
> > /sys/src/cmd/unix/u9fs/authp9any.c
> > authp9any.c.orig:369,375 - /n/sources/patch/u9fs-afid/authp9any.c:369,378
> > fprint(2, "p9anyattach: afid %d state %d\n", rx->afid, sp->state);
> > if (sp->state == Established && strcmp(rx->uname, sp->uname) == 0
> > && strcmp(rx->aname, sp->aname) == 0)
> /sys/src/cmd/unix/u9fs/authp9any.c
> authp9any.c.orig:369,375 -
> /n/sources/patch/u9fs-afid/authp9any.c:369,378
> fprint(2, "p9anyattach: afid %d state %d\n", rx->afid,
> sp->state);
> if (sp->state == Established && strcmp(rx->uname, sp->uname) == > 0
U9fs(4) misuses Fcall.afid in its p9any authentication module.
The afid field of Fcall structure is only valid with Tauth or Tattach.
Tread, Twrite, Tclunk should use rx->fid instead. It's been lucky so
far to get the job done because rx->afid survives from previous
Tauth/Tattach. The issue pops
14 matches
Mail list logo