Comparing hard coded 0 to a possibly negative SINTEGER

This is a function that wasn't working... it was returning 100 far too much of the time

DEFINE_FUNCTION INTEGER VOL_CONV_DB_NORMAL(SINTEGER nVAL){
    INTEGER nRESULT;
    if(nVAL < -500) return 0;
    if(nVAL > 0) return 100; // returns 100 when nVAL == -335

    // other stuff here doesn't get reached
}

This is the same function fixed

DEFINE_FUNCTION INTEGER VOL_CONV_DB_NORMAL(SINTEGER nVAL){
    INTEGER nRESULT;
    if(nVAL < -500) return 0;
    if(nVAL > -0) return 100; // does NOT return 100 when nVAL == -335

    // other stuff here gets reached
}

Notice the difference? It's tiny.

You would expect a comparison (-335 > 0) to come back false. And it would, if the data types were the same. Whenever you write a number hard in code NetLinx is going to treat it like a LONG, or an SLONG if it's negative. The parameter nVAL is an SINTEGER. For some reason, when it compares nVAL (containing -335) to the LONG value 0, it compares the SINTEGER -335 (binary 1000000101001111) to the LONG 0 (binary 00000000000000000000000000000000) and decides that -335 is bigger. But when comparing the SINTEGER -335 with the SLONG -0 (binary 10000000000000000000000000000000) it decides -0 is bigger?

That's what I think is going on at least. Comparing to -0 yielding a different result than comparing to 0 is silly, but if you think about what is probably going on with data type conversion of hard coded numbers, it kind of makes sense.

Something to keep in mind when dealing with negative numbers / signed & unsigned data types. If anyone here has a more accurate explanation of what's happening that would be great.