Message-ID: <3BD8EBA0.6EEE9EE9@yahoo.com>
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Errors and Standards, also RHIDE bug.
References: <01FD6EC775C6D4119CDF0090273F74A455A7B4 AT emwatent02 DOT meters DOT com DOT au> <3BD79C5D DOT 7A9E10AA AT yahoo DOT com> <200110260244 DOT EAA10378 AT goedel DOT fjf DOT gnu DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 155
Date: Fri, 26 Oct 2001 11:38:43 GMT
NNTP-Posting-Host: 12.90.173.144
X-Complaints-To: abuse AT worldnet DOT att DOT net
X-Trace: bgtnsc04-news.ops.worldnet.att.net 1004096323 12.90.173.144 (Fri, 26 Oct 2001 11:38:43 GMT)
NNTP-Posting-Date: Fri, 26 Oct 2001 11:38:43 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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)