  BASIC, GEM, Optimization, and error detection? 
 The Question is:
 
I've supplied two program examples which were compiled under DEC-BASIC ver
1.3
When I compile the first program, I only see the informational message if
the
optimizer is off. When I compile the second program, I only see the
informational
message when the optimizer is on. Is this normal?
 
Neil Rieck
Bell Canada (Kitchener, Ontario)
 
Example #1
 
$ type pos_demo.bas
1000    option type=explicit
        map(abc) string dev_name$ = 8             ! fixed length string
        dev_name$ = "LTA9999"
        if pos(dev_name$,":",1%)&gt;0% then
            dev_name$ = dev_name$ +":"            ! the problem
!~~~        dev_name$ = edit$(dev_name$128%) +":" x the fix
        end if
        print dev_name$
        end
$ bas/optim=level=0/warn=all pos_demo
 
            dev_name$ = dev_name$ +":"
 
%BASIC-I-EXPNOTRES, expression does not contribute to result
at line number 5 in file DKB0:[NEIL]POS_DEMO.BAS;4
$ bas/optim=level=1/warn=all pos_demo
$                                                 ! no informational
 
Example #2
 
$ type logic_demo.bas
1000    option type=explicit
        declare long rc%
        ! rc% = sys$qiow(bla...)
!~~~    if (rc% and 1%) &lt;&gt; 1% then &lt;-- what was intended
        if  rc% and 1%  &lt;&gt; 1% then
            print "error: ";rc%
        end if
        end
$ bas/optim=level=0/warn=all logic_demo           ! no informational
$ bas/optim=level=1/warn=all logic_demo
 
        if  rc% and 1%  &lt;&gt; 1% then
 
%BASIC-I-UNREACH, code can never be executed at label
at line number 5 in file DKB0:[NEIL]LOGIC_DEMO.BAS;2
 
 
 
 The Answer is:
 
  This behavior -- due to the way that the GEM code generation back-end
  operates -- has been around for some time, and also occurs in V1.2.
 
  The first example does initially appear odd, but the second example
  looks quite reasonable -- as for the latter case, it takes a higher
  level of optimization to see that the logical condition is always
  FALSE and thus the PRINT statement can never be executed.
 
  To understand the first example, note that dev_name$ is a fixed length
  string, so that catenating something to the end of it will not change
  its value.  At the lowest level of optimization GEM is able to detect
  that the statement will have no effect and so it puts out the message.
  With higher levels of optimization, the optimizer simple discards the
  unneed operation and produces the correct result similar to the
  optimization of arithmetic expressions (eg: y = x + 0).
 
  Note that because many of the arithmetic expressions are actually
  simplified by the compiler front-end before the GEM code optimizer
  is invoked, no message is output.
 
