')', ']', '}', 0, // CPAR
CR_DEFINED, CR_REFERENCED, // SUNARY (special unary)
CR_STREQ, CR_MACDEF,
- CR_DATE, CR_TIME, 0,
+ CR_DATE, CR_TIME,
+ CR_ABSCOUNT, 0,
'!', '~', UNMINUS, 0, // UNARY
'*', '/', '%', 0, // MULT
'+', '-', 0, // ADD
//
// Unary operators (detect unary '-')
+// ggn: If expression starts with a plus then also eat it up.
+// For some reason the parser gets confused when this happens and
+// emits a "bad expression".
//
int expr1(void)
{
class = tokenClass[*tok];
- if (*tok == '-' || class == UNARY)
+ if (*tok == '-' || *tok == '+' || class == UNARY)
{
t = *tok++;
{
switch ((int)*tok++)
{
+ case CR_ABSCOUNT:
+ *evalTokenBuffer++ = CONST;
+ *evalTokenBuffer++ = (LONG)sect[ABS].sloc;
+ break;
case CR_TIME:
*evalTokenBuffer++ = CONST;
*evalTokenBuffer++ = dos_time();
// 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 ((tok[1] == EOL)
- if ((tok[1] == EOL && tok[0] != CONST)
+ if ((tok[1] == EOL && (tok[0] != CONST && tokenClass[tok[0]] != SUNARY))
|| (((*tok == CONST || *tok == SYMBOL) || (*tok >= KW_R0 && *tok <= KW_R31))
&& (tokenClass[tok[2]] < UNARY)))
{