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.