[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More news from the trenches.
> Date: Thu, 21 Dec 95 14:57:31 +1000
> From: 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:
GuardCond mutated beyond recognition over christmas. I change the
offending code, please let me now if the new stuff proves to be too
difficult.
>
> * 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.
Corrected.
>
> * 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.
Corrected. Thank you very much for pointing out this problem to me in
such an explicit fashion. It made it very easy to track the error,
and to check if I got it right.
> The problems I reported earlier appear to have been fixed.
>
> Frank
If I manage to sort out some remaining problems I'll put the new
sources on cognac this evening.
-- mva