- // 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[1] == EOL is a single token that is)
- // Seems that even other tokens (SUNARY type) can fuck this up too.
-#if 0
-// if ((tok[1] == EOL)
- if ((tok[1] == EOL && ((tok[0] != CONST || tok[0] != FCONST) && tokenClass[tok[0]] != SUNARY))
-// || (((*tok == CONST || *tok == FCONST || *tok == SYMBOL) || (*tok >= KW_R0 && *tok <= KW_R31))
-// && (tokenClass[tok[2]] < UNARY)))
- || (((tok[0] == SYMBOL) || (tok[0] >= KW_R0 && tok[0] <= KW_R31))
- && (tokenClass[tok[2]] < UNARY))
- || ((tok[0] == CONST || tok[0] == FCONST) && (tokenClass[tok[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:
+ // 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: