Feature request: ability to specify exit code with ERR directive

[neilsf]

Hi
I'm sure that many people use DASM as part of a toolchain. I think it would be convenient if we could specify an exit code as a parameter of the ERR directive, for example:

ERR 1

This would exit DASM with an exit code 1. This way the next tool in the chain would know why the compilation failed and could be programmed to take appropriate action.
Currently the only way to solve this is to ECHO some kind of error code and try to parse the tail of DASM's output. It works but it is not very convenient.
What do you think?

PS. Okay, exit code 1 is a bad example, I can see now that DASM defines a lot of internal exit codes... but you get the idea.

[andrew-davie]

I'm doing a bit of dabbling just to look at this request.
Yes, dasm has internal error codes which it can return - in fact there are over 40 of them.
There are two basic approaches - an internal "panic" will simply exit with the value 1
A panic mostly happens when out of memory or if memory overflow detected.
There are also areas where panic is used as a result of incorrect command-line parameters being passed.
That isn't good usage, and I'll clean that up shortly.
The other approach is a bunch of hardwired return values based on the particular error.

ERROR_DEFINITION sErrorDef[] = {
    
    /* Error #, STOPEND, Description */
    
    { ERROR_NONE,                                   true,   "OK"   },
    { ERROR_COMMAND_LINE,                           true,   "Check command-line format."   },
    { ERROR_FILE_ERROR,                             true,   "Unable to open file."   },
    { ERROR_NOT_RESOLVABLE,                         true,   "Source is not resolvable."   },
    { ERROR_TOO_MANY_PASSES,                        true,   "Too many passes (%s)."   },
    { ERROR_NON_ABORT,                              true,   "See previous output"   },
    { ERROR_SYNTAX_ERROR,                           true,   "Syntax Error '%s'."   },
    { ERROR_EXPRESSION_TABLE_OVERFLOW,              true,   "Expression table overflow."   },
    { ERROR_UNBALANCED_BRACES,                      true,   "Unbalanced Braces []."   },
    { ERROR_DIVISION_BY_0,                          true,   "Division by zero."  },
    { ERROR_UNKNOWN_MNEMONIC,                       true,   "Unknown Mnemonic '%s'."   },
    { ERROR_ILLEGAL_ADDRESSING_MODE,                false,  "Illegal Addressing mode '%s'."   },
    { ERROR_ILLEGAL_FORCED_ADDRESSING_MODE,         true,   "Illegal forced Addressing mode on '%s'."   },
    { ERROR_NOT_ENOUGH_ARGUMENTS_PASSED_TO_MACRO,   true,   "Not enough args passed to Macro."   },
    { ERROR_PREMATURE_EOF,                          false,  "Premature EOF."   },
    { ERROR_ILLEGAL_CHARACTER,                      true,   "Illegal character '%s'."   },
    { ERROR_BRANCH_OUT_OF_RANGE,                    false,  "Branch out of range (%s bytes)."   },
    { ERROR_ERR_PSEUDO_OP_ENCOUNTERED,              true,   "ERR pseudo-op encountered."  },
    { ERROR_ORIGIN_REVERSE_INDEXED,                 false,  "Origin Reverse-indexed."   },
    { ERROR_EQU_VALUE_MISMATCH,                     false,  "EQU: Value mismatch."   },
    { ERROR_ADDRESS_MUST_BE_LT_100,                 true,   "Value in '%s' must be <$100."  },
    { ERROR_ADDRESS_MUST_BE_LT_10000,               true,   "Value in '%s' must be <$10000."  },
    { ERROR_ILLEGAL_BIT_SPECIFICATION,              true,   "Illegal bit specification."   },
    { ERROR_NOT_ENOUGH_ARGS,                        true,   "Not enough arguments."   },
    { ERROR_LABEL_MISMATCH,                         false,  "Label mismatch...\n --> %s"  },
    { ERROR_MACRO_REPEATED,                         true,   "Macro \"%s\" definition is repeated."  },
    { ERROR_VALUE_UNDEFINED,                        true,   "Value Undefined."   },
    { ERROR_PROCESSOR_NOT_SUPPORTED,                true,   "Processor '%s' not supported."  },
    { ERROR_REPEAT_NEGATIVE,                        false,  "REPEAT parameter < 0 (ignored)."   },
    { ERROR_BADERROR,                               true,   "Bad error value (internal error)." },
    { ERROR_ONLY_ONE_PROCESSOR_SUPPORTED,           true,   "Only one processor type may be selected." },
    { ERROR_BAD_FORMAT,                             true,   "Bad output format specified." },
	{ ERROR_VALUE_MUST_BE_1_OR_4,					true,   "Value in '%s' must be 1 or 4." },
	{ ERROR_VALUE_MUST_BE_LT_10,					true,   "Value in '%s' must be <$10." },
	{ ERROR_VALUE_MUST_BE_LT_8,						true,   "Value in '%s' must be <$8." },
	{ ERROR_VALUE_MUST_BE_LT_F,						true,   "Value in '%s' must be <$f." },
	{ ERROR_VALUE_MUST_BE_LT_10000,					true,   "Value in '%s' must be <$10000." },
	{ ERROR_ILLEGAL_OPERAND_COMBINATION,			true,   "Illegal combination of operands '%s'" },
	{ ERROR_RECURSION_TOO_DEEP,                     true,   "Recursion too deep in %s" },
	{ ERROR_AVOID_SEGFAULT,				            true,   "Internal error in %s" },
	{ ERROR_MISSING_ENDM,				            true,   "Unbalanced macro %s" },
	{ ERROR_MISSING_COMMENT_END,			        true,   "Multi-line comment not closed." },
	{ ERROR_SPURIOUS_COMMENT_CLOSE,			        true,   "Multi-line comment closed without open." },
    { ERROR_INVALID_ERROR_FORMAT,                   true,   "Invalid error format for -E, must be 0, 1, 2." },
    { ERROR_INVALID_SORTING_MODE,                   true,   "Invalid sorting mode for -T option, must be 0 or 1." },
    { ERROR_ILLEGAL_FORMAT_SPECIFICATION,           true,   "Illegal format specification for -f option." },
    { ERROR_NO_FILE_NAME,                           true,   "-o Switch requires file name." },
    { ERROR_M_SWITCH,                               true,   "-m Switch invalid argument, should be > 64." },
    { -1,                                           true,   "Doh! Internal end-of-table marker, report the bug!"},
};

I added a few in my own codebase just to check/look at the panic stuff.

I think perhaps if we allow user errors from 128 onwards (or 64, if it must be smaller), that would fit with dasm's current exit strategy.

[neilsf]

It looks like codes 3-125 and 166-254 can be user-defined exit codes (at least on Linux):
https://tldp.org/LDP/abs/html/exitcodes.html

[msaarna]

Pretty sure those are specific to the bash process itself.

In terms of system standards, there's the sysexits.h file, which on my Linux build ends at signal 78. It's also my understanding that sysexits.h is rarely followed.