you will need to fix AMLOP_ONES as well. It does a (char)opcode typecast,
which would be 0xff not 0xffff... if using uint64.
amlop_match, amlop_wait, amlop_acquire, amlop_condref all will need to return
AML_ONES or AML_TRUE
> Date: Sun, 1 Apr 2012 10:45:55 +0300
> From: p...@irofti.net
> To: o...@drijf.net
> CC: tech@openbsd.org; kette...@openbsd.org; chas...@skynet.be;
jor...@openbsd.org
> Subject: Re: aml: Fix integer types to be unsigned
>
> On Sat, Mar 31, 2012 at 05:33:33PM +0200, Otto Moerbeek wrote:
> > On Sat, Mar 31, 2012 at 01:47:18AM +0300, Paul Irofti wrote:
> >
> > > After the report from a few weeks ago I went ahead and fixed most (if
> > > not all) of the signed integer usages in the AML parser.
> > >
> > > Please have a look at this diff, test it thoroughly and comment/okay
it.
> >
> > Some comments inline.
> >
> > > +_aml_setvalue(struct aml_value *lhs, int type, u_int64_t ival, const
void *bval)
> > > {
> > > memset(&lhs->_, 0x0, sizeof(lhs->_));
> > >
> > > @@ -923,7 +920,7 @@ _aml_setvalue(struct aml_value *lhs, int
> > > memcpy(lhs->v_buffer, bval, ival);
> > > break;
> > > case AML_OBJTYPE_STRING:
> > > - if (ival == -1)
> > > + if ((signed)ival == -1)
> >
> > Very a-typical way of doing this. Better cast the constant to the
> > target type, that's the comon idiom. (signed) is a shorthand for
> > (signed int) and not (the signed variant of the type). It is very
> > uncommon to use it.
>
> Yes, I had some issues with casting on the other side (which is what I
> tried first). Yes, I know now, that (signed) expands to (signed int).
> Well I think I knew that in the passed but the brain cells holding that
> information must've quit and moved on to a smarter brain.
>
> So the solution, I think, will be to check against (0xffff..ff)
> constants and stop casting.
>
> The problem here was that I got values in ival that were
> 32-bit and also 64-bit versions of -1.
