Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!mucs!liv-cs!rkl From: rkl@mva.cs.liv.ac.uk Newsgroups: comp.sys.hp Subject: HP9000 Pascal Buglist / Wishlist Message-ID: <2258@mva.cs.liv.ac.uk> Date: 3 Oct 89 16:00:54 GMT Organization: Computer Science CSMVAX, Liverpool University Lines: 134 We are currently running HP-UX 3.1 on an HP9000/850 and HP-UX 6.2 on various HP9000 Series 300 workstations. Since there has just been a very interesting posting on HP-UX 3.1 problems, I thought I'd weigh in with a similar document about HP Pascal. Firstly, here's a list of currently strange 'features' (bugs to you and me) : 1. Extremely large executable size (On Series 800 machines only) ------------------------------- Try compiling the following HP Pascal program on a Series 800 machine... (WARNING: Make sure you have at LEAST 250 MBs of free disk space !) program bigexec ( input , output ) ; type str255 = string [ 255 ] ; var huge : array [ 1..1000 , 1..1000 ] of str255 ; begin writeln ( 'If you get this far, then you have plenty of disk space !' ) end. Although this would normally be dismissed as a downright inefficient way of building an s800 executable (what's wrong with a malloc at run-time ?), this really does highlight the lack of disk quotaing (HP-UX 7.0 should cure this) - any normal user can fill the disk in less than one minute. Compiling the same program on Series 300 machines results in a less dramatic executable size (69K). 2. Otherwise clause in a Case statement is compulsory at run-time -------------------------------------------------------------- If the case statement falls through all the selector values without matching ANY of them at run-time, then the otherwise clause MUST be present. I'm sure most Pascals just fall out of the case statement without an error. The worst thing about this is that it is not reported at compile-time - leading to programs that could be potentially crashable when they really shouldn't be. 3. 'Accessed, but not initialised' compile-time warning ---------------------------------------------------- This appears on the Series 800 Pascal if you attempt to access a variable before it has been initialised. I'd like to see this warning on the Series 300 Pascal too - it's quite handy (and can be switched off if it annoys you with $WARN OFF$). 4. close ( filevar ) doesn't have a sensible default behaviour (Series 300) ----------------------------------------------------------- When a file is opened for output with the rewrite statement, using the close statement with only the file variable as a parameter not only closes the file BUT DELETES IT. This is exactly the opposite behaviour of all other Pascals I have come across. Yes, you can specify close ( filevar , 'SAVE' ), but you shouldn't have to. 5. The + operator for strings is fussy about its operands ------------------------------------------------------ Quiz time ! Which of the following is legal in HP Pascal (fred is a string) ? a) fred := fred + '*' ; b) fred := fred + chr ( 42 ) ; c) bill := '*' ; fred := fred + bill ; { bill is a char } Answer: a) and b) both work on Series 300 machines. Only a) works on Series 800 machines. c) works on neither ! This is incredibly inconsistent behaviour - my opinion is that all three should be perfectly legal. The rest of these points are a wishlist for HP Pascal: 1. Array slicing ------------- I really miss the ability to do: var fred : array [ 1..7 , 1..7 ] of integer ; begin fred [ 1 , ] := fred [ 2 , ] end ; { OK, so it's uninitialised... } 2. Constant assignment to arrays (and other types ?) in the var section -------------------------------------------------------------------- Again, I miss this lovely construct: var fred : array [ 1..2 , 1..2 ] of integer := ( ( 17 , 6 ) , ( 13 , -2 ) ) ; It saves having to put the data in a text file (or 100's of assignments). 3. Access to external ints in C library routines --------------------------------------------- Whilst attempting to call curses routines from Pascal (yes, Frank, I noticed the flaky curses routines too !), I had to resort to C 'glue' routines to get at external ints inside the curses library, even though HP Pascal *can* call external functions and procedures. 4. Executable size seems rather large (300 or 800 Series) ------------------------------------------------------ Now I know that there aren't shared libraries in HP-UX 3.1, but even so, a size of 60 to 70 K (300 Series) or 150 K upwards (800 Series) for the most trivial of programs seems a bit on the gargantuan side. And people complain about the size of C executables ! 5. Series 300 optimisation ----------------------- Call me stupid if you want, but I can't understand why pc on the Series 800 has a -O option (optimisation), but the Series 300 pc does not... Conclusion ---------- As I think has already been mentioned, it is clear that Series 300 and Series 800 Pascal are written by different people within HP. This does lead to differences in HP Pascal behaviour that, whilst not difficult to work around, are just a little bit too niggly to go away that easily. Although I have made some negative points about HP Pascal, I am actually reasonably impressed, syntax-wise, with it and would be delighted if some of the suggestions/bugs were implemented/fixed in some future release. Richard K. Lloyd, **** This is a MicroVAX II running VAX/VMS V5.1 **** Computer Science Dept., * JANET : RKL@UK.AC.LIV.CS.MVA or * Liverpool University, * RKL@000010500211.FTP.MAIL * Merseyside, England, * Internet : RKL%mva.cs.liv.ac.uk@cunyvm.cuny.edu * Great Britain. ****************************************************