[M3devel] turning off checking?
estellnb at elstel.org
Tue Jul 29 17:32:43 CEST 2014
It would be a particularely bad idea to turn off checking as a whole for
most use cases; i.e. f.i. just because there is one code snipped which
does not work with these checks. It should be possible to switch of
range checks i.e. integer underflow and overflow checks for a paticular
code block; there could be a different switch for array index range
checks and so on. Concerning the automaton simulator which I had started
to port to Modula-3 last year there was one such snippet which could
only be made working by an explicit type conversion to longint, applying
a logical and and then converting back to integer - and that for several
times. The code has become almost unreadable by the many type
conversions which are basically unnecessary and degrading performance.
Consequently I would really appreciate such switches on a per-code block
Am 24.07.14 22:06, schrieb Rodney M. Bates:
> On 07/24/2014 05:08 AM, mika at async.caltech.edu wrote:
>> I added M3_OPTIONS=["NoChecks"] to my cm3.cfg:
>> (62)truffles:~/t/btc/hsim/gcrit/src>cm3 -x
>> --- building in ../AMD64_LINUX ---
>> new source -> compiling CardCritAttrTbl.i3
>> m3c: unknown option, "NoChecks"
> Some grepping and reading suggest this message comes from
> procedure ProcessArg. This would accept "-NoChecks", note the dash.
> Some more poking around reveals it gets these options from Quake
> M3_OPTIONS and M3_FRONT_FLAGS.
> Despite the name "ProcessArgs" and the use of dashes on everything, these
> don't appear to be command line options, which are handled in entirely
> different paths. Command line "-A" looks to get converted to
> and appended to M3_OPTIONS by generated Quake code, to be interpreted
> There are a few other such conversions, but nothing else starting with
>> Fatal Error: failed compiling:
> Snip -------
More information about the M3devel