More news from the trenches.

[Frank Copeland <fjc@wossname.apana.org.au>]

Hi Michael and Juergen,

In compiling the latest (951218) sources under Oberon-A I've encountered
some problems that need attention.

  * In frontend/GuardCond.mod, lines 111-114, the expression is too
    complicated for Oberon-A. I've replaced it in my sources with:

      ELSIF (merge. opndList. arg IS D.Guard) &
        (merge. opndList. nextOpnd. arg IS D.Guard) THEN
        IF (merge. opndList. arg(D.Guard). opndList. arg =
            merge. opndList. nextOpnd. arg(D.Guard). opndList. arg) THEN

          ...

        END
      END

  * When compiling frontend/first_steps/Type.mod, OOC suffers an NIL
    pointer trap in module Data.mod, at line 626, col 24. This appears to
    occur when OOC reaches pos 199 in the source file.

  * There is a problem when reading symbol files containing the following
    kind of construct:

      TYPE
        T1Ptr = POINTER TO T1;
        T1 = RECORD
          f1 : T1Ptr;
          ...
        END;

    This can be observed by compiling any module that imports module Files
    as defined in optimizers/libstubs/Files.mod. The problem appears to be
    that StdTypes.StructAlloc() is called for T1 *before* being called for
    T1Ptr. The default size given to T1Ptr by Data.InitStruct() is
    MIN(LONGINT), and this value is being used to calculate the size and
    field offsets for T1. In extreme cases this causes arithmetic
    overflows in StdTypes.StructAlloc(). I've added logging statements to
    my version of StdTypes that illustrate the problem. Call OOC with the
    -log argument to activate the logging.

The problems I reported earlier appear to have been fixed.

Frank