Mail Archives: djgpp/2001/10/26/07:49:16
Frank Heckenbach wrote:
>
> CBFalconer wrote:
>
> > Aside - I prepared a text version of ISO10206 and sent it to Frank
> > a few days ago. I have not heard anything back from him. It
> > seems like a good thing to have around for instant searches, etc.
> > I wonder if he received it?
>
> Yes, I did. However, are we allowed to distribute it at all? What is
> the copyright status of the document?
The following was in the original:
===========
This online copy of the Extended Pascal standard is provided only
as an aid
to standardization. In the case of differences between this online
version
and the printed version, the printed version takes precedence.
Do not modify this document. Do not include this document in
another
software product. You may print this document for personal use
only. Do not
sell this document.
===========
I have not modified it. I take the above as permission to
promulgate it. Even if I am wrong, the worst that could happen
would be for ISO to ask you to withdraw it.
>
> > I consider the lack of range-checking to be the worst failing of
> > GPC. The point of using Pascal is to have ones hand held and to
> > generate safe code. Without range checks one might as well use C.
>
> I thought so too when I came to GPC. However, in the years I've
> found that it was not that bad, at least for me (not meaning to
> justify GPC's failure, of course).
>
> It is still one of the top-priority bugs. OTOH, there was recently
> quite some consensus on finishing a 2.1 release soon. Afterwards,
> range checking should be one of the next features implemented.
The standard says "It shall be an error ....".
In another newsgroup there was discussion of an algorithm
(comp.programming) and I generated the following. I left the
"abs" out of the hash procedure, and things failed. The system
was returning negative values used as indices, and I consider it a
minor miracle that there were no spectacular crashes. This should
never have happened.
(Below is some further discussion about a rhide bug detected with
this)
PROGRAM On(input, output);
(* ISO standard Pascal *)
LABEL 9;
CONST
tblsize = 17;
(* a suitable prime, larger than the maximum *)
(* count of discrete entries to be read *)
criterion = 5; (* count of items needed to keep *)
TYPE
natural = 1 .. tblsize;
VAR
item : integer;
i, h, h2, h0 : natural;
hashtbl : ARRAY[1..tblsize] OF RECORD
value : integer;
count : 0..criterion;
END;
FUNCTION hash(n : integer) : natural;
(* create these. This is too simple for efficiency *)
BEGIN (* hash *)
hash := (abs(n) MOD tblsize) + 1;
END; (* hash *)
FUNCTION rehash(n : integer) : natural;
(* This is also overly simple for efficiency *)
BEGIN (* rehash *)
rehash := 1;
END; (* rehash *)
BEGIN (* On *)
FOR i := 1 TO tblsize DO hashtbl[i].count := 0; (* init *)
REPEAT
readln(item);
h := hash(item);
IF hashtbl[h].count = 0 THEN BEGIN (* new *)
hashtbl[h].count := 1;
hashtbl[h].value := item; END
ELSE IF hashtbl[h].value = item THEN BEGIN (* found *)
IF hashtbl[h].count < criterion THEN
hashtbl[h].count := hashtbl[h].count + 1; END
ELSE BEGIN (* collision occured *)
h0 := h;
h2 := rehash(item); (* nonzero MOD tblsize *)
REPEAT
h := ((h + h2) MOD tblsize) + 1;
IF h = h0 THEN BEGIN
writeln('Full'); goto 9; END;
IF hashtbl[h].count = 0 THEN BEGIN (* new *)
hashtbl[h].count := 1;
hashtbl[h].value := item; END
ELSE IF hashtbl[h].value = item THEN BEGIN (* found *)
IF hashtbl[h].count < criterion THEN
hashtbl[h].count := hashtbl[h].count + 1; END
UNTIL hashtbl[h].value = item;
END;
UNTIL eof;
9:
(* dump results *)
FOR i := 1 TO tblsize DO
WITH hashtbl[i] DO
IF count >= criterion THEN
writeln(value, ' hash = ', i : 1, ' KEPT')
ELSE IF count > 0 THEN
writeln(value, ' count = ', count : 3, ' hash = ', i : 1);
END. (* On *)
========= RHIDE bug under DJGPP - reason for cross post ========
The input is terminated by an EOF. Under rhide, having once
terminated a run, input was found to be permanently at EOF. Doing
a program reset did not clear it. The only way to loosen up the
system was to exit RHIDE completely, and restart it. I have no
objection to the EOF sticking (in fact I approve), but a reset
should reset!
It was just as well in this case, because I am set up to create
further checking under command line use, which showed up the use
of extensions (i.e. halt and inc).
(To generate EOF enter a CTL-Z under DJGPP)
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:uce AT ftc DOT gov (for spambots to harvest)
- Raw text -