Home AMX User Forum AMX Technical Discussion

RSHIFT compiler warning

I'm getting a compiler warning Converting type LONG to INTERGER with this function, specificaly the RSHIFT. When I remove the RSHIFT it compiles fine.

DEFINE_FUNCTION INTEGER[2] fnWord12(CHAR Word[])
{
STACK_VAR INTEGER Result[2]
Result[1] = ($1F BAND Word[1]) // First piece of info is in the first five bits
Result[2] = ($03 BAND (Word[1] RSHIFT 5)) // second piece of info is in bits 6&7
RETURN Result;
}

Is there something about RSHIFT I'm not understanding?

Comments

  • Joe HebertJoe Hebert Posts: 2,159
    I don?t understand why the warning either but you can quiet it with a TYPE_CAST.

    Result[2] = TYPE_CAST(($03 BAND (Word[1] RSHIFT 5)))
  • Joe Hebert wrote:
    I don?t understand why the warning either but you can quiet it with a TYPE_CAST.

    I suppose it's because the Variable Word[] was initialized a CHAR and its assigned to an INTEGER
  • TonyAngeloTonyAngelo Posts: 315
    I suppose it's because the Variable Word[] was initialized a CHAR and its assigned to an INTEGER

    I don't believe that's the case. It's giving me a LONG to INTEGER warning and when I comment out the Result[2] line I get no warnings. The Result[1] line which does the same thing (assigns the BANDed result of Word[] to an integer) gives me no problems.

    TYPE_CAST will work, but I just wanted to make sure this was the right way to use RSHIFT and I wasn't missing something.
  • TonyAngelo wrote:
    TYPE_CAST will work, but I just wanted to make sure this was the right way to use RSHIFT and I wasn't missing something.

    Sometimes you do, and sometimes you don't need to type_cast - so don't worry about it.
  • DHawthorneDHawthorne Posts: 4,584
    It's been my experience that type checking in NetLinx is not 100% consistent. This looks to be one of those cases. I suspect it is because of automatic conversions on an expression and precedence rules, and internally it might not be as wonky as it appears to us when it happens.
  • Perhaps I should clarify that while the netLinx compiler does get some stuff wrong, it doesn't seem to get type_cast wrong, whether or not the compiler requires it to be explicit.

    Counter-examples welcomed...
Sign In or Register to comment.