On 30 May 2014 14:03, Julius Schmidt wrote:
> Comparing an int to a u16int causes the int to be cast to unsigned int,
> instead of the u16int being promoted to int and then compared (as I would
> argue the C89 standard specifies).
Ken's compiler implements the original unsigned-preserving rule
I have found what I believe to be a compiler bug: Comparing an int to a
u16int causes the int to be cast to unsigned int, instead of the u16int
being promoted to int and then compared (as I would argue the C89
standard specifies).
As a result -1 < u is false for any u16int u. Or is this intende
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
13 matches
Mail list logo
