Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!lins From: lins@Apple.COM (Chuck Lins ) Newsgroups: comp.lang.modula2 Subject: Re: Bug in Oberon-M (MS-DOS)? Summary: Yes, at least 2 bugs in Oberon-M :-) Keywords: ARRAY OF pointertype Message-ID: <52977@apple.Apple.COM> Date: 16 May 91 23:18:13 GMT References: <1707@gufalet.let.rug.nl> Organization: Apple Computer Inc, Cupertino, CA Lines: 51 In article <1707@gufalet.let.rug.nl> bert@let.rug.nl (Bert Bos) writes: > >While trying to write a Quicksort routine in Oberon-M, I found the >following weird behaviour. Program 1 is incorrect, while program 2 is >accepted by the compiler: > >(* 1 *) MODULE test; (* this program doesn't compile *) > TYPE Object = POINTER TO ObjectRec; > ObjectRec = RECORD END; > > PROCEDURE p(VAR x: ARRAY OF Object); > VAR h: Object; > ^^^^^^^^^ > BEGIN h:= x[0] END p; > > BEGIN END test. > This program is correct and should be accepted by the compiler. >(* 2 *) MODULE test2; (* this program does compile *) > TYPE Object = POINTER TO ObjectRec; > ObjectRec = RECORD END; > > PROCEDURE p(VAR x: ARRAY OF Object); > VAR h: ObjectRec; > ^^^^^^^^^^^^ > BEGIN h:= x[0] END p; > > BEGIN END test2. > >Is this a bug, or is Oberon supposed to treat arrays of pointers as >arrays of records? If it isn't a bug, how else do you create an array >of elements of unspecified (i.e. extended) type? This second example should given a compile error as the assignment of a pointer to a record type is illegal. The correct statement should be h := x[0]^ in module test2. Thus, Oberon-M has several bugs of both type I and type II: * it reported an error where there is none, * it did not report an error when one was present. -- Chuck Lins | "Is this the kind of work you'd like to do?" Apple Computer, Inc. | -- Front 242 20525 Mariani Avenue | Internet: lins@apple.com Mail Stop 37-BD | AppleLink: LINS@applelink.apple.com Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist" The intersection of Apple's ideas and my ideas yields the empty set.