- // Shamus: Subtle bug here. EOL token is 101; if you have a constant token
- // followed by the value 101, it will trigger a bad evaluation here.
- // This is probably a really bad assumption to be making here...!
- // (assuming tok.u32[1] == EOL is a single token that is)
- // Seems that even other tokens (SUNARY type) can fuck this up too.
-#if 0
-// if ((tok.u32[1] == EOL)
- if ((tok.u32[1] == EOL && ((tok.u32[0] != CONST || tok.u32[0] != FCONST) && tokenClass[tok.u32[0]] != SUNARY))
-// || (((*tok.u32 == CONST || *tok.u32 == FCONST || *tok.u32 == SYMBOL) || (*tok.u32 >= KW_R0 && *tok.u32 <= KW_R31))
-// && (tokenClass[tok.u32[2]] < UNARY)))
- || (((tok.u32[0] == SYMBOL) || (tok.u32[0] >= KW_R0 && tok.u32[0] <= KW_R31))
- && (tokenClass[tok.u32[2]] < UNARY))
- || ((tok.u32[0] == CONST || tok.u32[0] == FCONST) && (tokenClass[tok.u32[3]] < UNARY))
- )
-#else
-// Shamus: Seems to me that this could be greatly simplified by 1st checking if the first token is a multibyte token, *then* checking if there's an EOL after it depending on the actual length of the token (multiple vs. single). Otherwise, we have the horror show that is the following:
- if ((tok.u32[1] == EOL
- && (tok.u32[0] != CONST && tokenClass[tok.u32[0]] != SUNARY))
- || (((tok.u32[0] == SYMBOL)
- || (tok.u32[0] >= KW_R0 && tok.u32[0] <= KW_R31))
- && (tokenClass[tok.u32[2]] < UNARY))
- || ((tok.u32[0] == CONST) && (tokenClass[tok.u32[3]] < UNARY))
+ // Shamus: Seems to me that this could be greatly simplified by 1st
+ // checking if the first token is a multibyte token, *then*
+ // checking if there's an EOL after it depending on the actual
+ // length of the token (multiple vs. single). Otherwise, we have
+ // the horror show that is the following:
+ if ((tok[1] == EOL
+ && (tok[0] != CONST && tokenClass[tok[0]] != SUNARY))
+ || ((tok[0] == SYMBOL)
+ && (tokenClass[tok[2]] < UNARY))
+ || ((tok[0] == CONST) && (tokenClass[tok[3]] < UNARY))