Re: [Gm2] Re: LENGTH() on Solaris 10/sparc

[Fischlin Andreas]

Dear Gaius,

One last attempt. Afterwards I will give up. Promised. ;-)

___________________

Gaius wrote:

ok - I'll change this - probably to use a procedure function returning
TRUE on success.


___________________

af writes: Excellent

___________________

Gaius wrote:

I'll rename Terminate to ExecuteTerminationProcedures.  Maybe we need
a procedure function to determine whether we are in the Termination
phase as well.



___________________

af writes: In my understanding not quite the same or not necessary the same. I 
expect Terminate to be a really low level call to the hardware halting the 
currently running process. However, ExecuteTerminationProcedures does nothing 
of the sort. It merely executes all installed termination procedures. A typical 
sequence would then be

ExecuteTerminationProcedures; Terminate;

In particular in a dynamic loader situation, Terminate would merely abort the 
current level and leave the rest of the process stack intact.

The question also arises what is the relationship to HALT. HALT may be the same 
as Terminate, in particular in a single level system as all statically linked 
run-time environments such as that of C are. But as a n implementer you are 
free to also interpret HALT as simply first breaking the program, as any other 
break point set, and allow the user the choice of either calling the debugger 
or perhaps continuing the process if no abnormal condition was encountered or 
to abort the program. Only in the last situation you would then call

ExecuteTerminationProcedures; Terminate;

This would allow to debug the running data/code BEFORE the termination 
procedures have made their garbage collection.

___________________

Gaius wrote:

Agreed there is no dynamic module loading possible, since our times
entrench on us the stone age of only static linking and unmodular
programming style, but nevertheless I am not sure whether it would
not be beneficial for having the symmetrical procedures available as
well.

PROCEDURE InstallInitProcedure (p: PROC; VAR done: BOOLEAN) ;
PROCEDURE ExecuteInitProcedures;

sure I'll implement this - the ExecuteInitProcedures will be called by
default just before the main program module BEGIN code.

___________________

af writes: Exellent and exactly what is needed.

___________________

Gaius wrote:

I believe the StrLib.StrEqual code behaves in the same way as StrEqual
above.  (It uses StrLen to determine the length of the strings under
comparison which handles the ASCII.nul case).  Unless I've
misunderstood something?


___________________

af writes: You are right, I read this code too quickly. What confused me is the 
use of the variable name Higha and Highb, which are basically wrong names. The 
names are misleading, since a statement like

Higha := StrLen(a) ;

should rather be written as

lena := StrLen(a) ;

since HIGH and LENGTH have little to do with each other. My problem was just 
the poor variable naming. Thus the code should better be written as


PROCEDURE StrEqual (a, b: ARRAY OF CHAR) : BOOLEAN ;
VAR
   i, lena, lenb: CARDINAL ;
   equal: BOOLEAN ;
BEGIN
   lena := StrLen(a) ;
   lenb := StrLen(b) ;
   IF lena=lenb
   THEN
      equal := TRUE ;
      i := 0 ;
      WHILE equal AND (i<lena) DO
         equal := (a[i]=b[i]) ;
         INC(i)
      END ;
      RETURN( equal )
   ELSE
      RETURN( FALSE )
   END
END StrEqual ;


But above routine is IMHO still not a particularly good one, since it is very 
inefficient. It makes at least 2 and up to 4 passes through the 2 string 
variables, while my proposals make up to a max of 2 passes as unavoidable. If 
the two strings differ in the first char, that first char comparison is all 
what is needed and the routine already returns FALSE. Please replace above 
routine with one of mine's. That may quite matter with large string arrays.

Regards, Andreas


ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich
SWITZERLAND

address@hidden<mailto:address@hidden>
www.sysecol.ethz.ch<http://www.sysecol.ethz.ch>

+41 44 633-6090 phone
+41 44 633-1136 fax
+41 79 221-4657 mobile

             Make it as simple as possible, but distrust it!
________________________________________________________________________