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.

Reply via email to