Fix hex parsing, readme typos.

ReadMe.md

@@ -195,7 +195,7 @@ of Einstein and Antoine de Saint-Exupéry:
 ###### Oberon 2
  - [Differences between Oberon and Oberon-2](http://members.home.nl/jmr272/Oberon/Oberon2.Differences.pdf)
  - [The Programming Language Oberon-2](http://www.ssw.uni-linz.ac.at/Research/Papers/Oberon2.pdf)
- - [Programming in Oberon. Steps beyond Pascal and Modula](www.ethoberon.ethz.ch/WirthPubl/ProgInOberonWR.pdf)
+ - [Programming in Oberon. Steps beyond Pascal and Modula](http://www.ethoberon.ethz.ch/WirthPubl/ProgInOberonWR.pdf)
  - [The Oakwood Guidelines for Oberon-2 Compiler Developers](http://www.math.bas.bg/bantchev/place/oberon/oakwood-guidelines.pdf)
 
 ###### Oberon 07

doc/Installation.md

@@ -32,7 +32,7 @@ The following type sizes follow the built compiler size:
 | Types          | 32 bit builds | 64 bit builds |
 | -----          | ------------- | ------------- |
 | INTEGER        | 16 bit        | 32 bit        |
-| LONGINT, SET   | 32 bit        | 16 bit        |
+| LONGINT, SET   | 32 bit        | 64 bit        |
 
 Note that many library modules have been written with the assumption that INTEGER
 is 16 bit and LONGINT 32 bit, therefore they will only work in 32 bit builds.

doc/Roadmap.md

@@ -66,6 +66,29 @@ means client code does not need changing.
 
 This fixes the current 16 bit hole in the range of INTEGER types on 64 bit systems.
 
+#### Oakwood Guidelines on type sizes
+
+The Oakwood guidelines are interesting.
+
+  - 5.2 requires that e.g. LONGINT is 32 bits *or more*,
+
+but
+  - Appendix A 1.2.5.4 requires that MODULE Files *always* reads and writes
+    LONGINT as 4 bytes.
+
+The restriction for the Files module makes sense as it is intended to produce
+and consume files in a compatible way between platforms. Thus if a system uses
+64 bit LONGINT, it is an error (detected or not) to write
+to MODULE Files any LONGINT values outside the 32 bit range.
+
+To put it shockingly, it is an error to write the vast majority of possible
+LONGINT values - specifically over 99.998% of LONGINT values are invalid for
+MODULE Files.
+
+I see this as another argument in favour of locking LONGINT down as 32 bits.
+
+
+
 
 #### A feature I'd really like to see
 

src/compiler/OPM.cmdln.Mod

@@ -31,7 +31,6 @@ MODULE OPM;  (* RC 6.3.89 / 28.6.89, J.Templ 10.7.89 / 22.7.96  *)
 
     MaxRExp*        = 38;
     MaxLExp*        = 308;
-    MaxHDig*        = 8;
 
     MinHaltNr*      = 0;
     MaxHaltNr*      = 255;

src/compiler/OPS.Mod

@@ -90,7 +90,7 @@ MODULE OPS;  (* NW, RC 6.3.89 / 18.10.92 *)    (* object model 3.6.92 *)
   END Identifier;
 
   PROCEDURE Number;
-    VAR i, m, n, d, e: INTEGER; dig: ARRAY 24 OF CHAR; f: LONGREAL; expCh: CHAR; neg: BOOLEAN;
+    VAR i, m, n, d, e, maxHdig: INTEGER; dig: ARRAY 24 OF CHAR; f: LONGREAL; expCh: CHAR; neg: BOOLEAN;
 
     PROCEDURE Ten(e: INTEGER): LONGREAL;
       VAR x, p: LONGREAL;
@@ -136,8 +136,9 @@ MODULE OPS;  (* NW, RC 6.3.89 / 18.10.92 *)    (* object model 3.6.92 *)
           ELSE err(203)
           END
         ELSIF ch = "H" THEN (* hexadecimal *) OPM.Get(ch); numtyp := integer;
-          IF n <= OPM.MaxHDig THEN
+          IF MAX(LONGINT) > 2147483647 THEN maxHdig := 16 ELSE maxHdig := 8 END;
-            IF (n = OPM.MaxHDig) & (dig[0] > "7") THEN (* prevent overflow *) intval := -1 END;
+          IF n <= maxHdig THEN
+            IF (n = maxHdig) & (dig[0] > "7") THEN (* prevent overflow *) intval := -1 END;
             WHILE i < n DO intval := intval*10H + Ord(dig[i], TRUE); INC(i) END
           ELSE err(203)
           END