Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <35517D9C.1019@rug.ac.be>
Date: Thu, 07 May 1998 11:23:40 +0200
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Nate Eldredge <nate AT cartsys DOT com>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: Far string/mem functions available for testing
References: <Pine DOT LNX DOT 3 DOT 96 DOT 980430170750 DOT 187A-100000 AT unixbox DOT bitbucket DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Nate Eldredge wrote:
> I have uploaded my far pointer string/mem function package for testing.

This first ``bug''-report was from looking at the sources alone. I've
nothing compiled yet. Other tests results will follow.
I'm not very explanative here below. Please ask if I am not clear about
something. 
I post this to c AT m-d because if I might be wrong about something someone
may want to correct me.

-----
Move/Push to/from seg regs can be lword -> faster and shorter encoding
When pointer to result is NULL -> should yield undefined behaviour
(meaning: libc functions shouldn't test it).
Count parameter should always have have type size_t (function
_farmemcpy).
typedef for seg and ofs seems a good idea.
``FIXME string operations'' remarks: FYI they are not generally slow
when they are
repz/repnz-ed. Intel knows where they are used for (I hope ;-)
Determining the length of a string is relatively an expensive operation.
_farstrchr therefore is not implemented well, IMO. Consider a string of
260
spaces. Using strchr to search for every space consecutively creates a
O(n^2)
algo because the first time 261 bytes are visited, next time 260, ... ,
2,
1.
The same but in lesser extend applies to _farstrcmp .
This also allows for the following type of optimizations (quite
important
time opt.):
  Orig:
    len = strlen (s)+1;
    d = malloc (len);
    strcpy (d, s);
  Better:
    len = strlen (s)+1;
    d = malloc (len);
    memcpy (d, s, len);
  f.i. _farstrdup (and strdup) could be optimized using this technique
_farstrcat contains a bug.
_farstrcspn seem to contain a loop that may never end. At least that is
how I would think when I were a compiler.
_farstrrchr may not work with an ofs = 0.

I've a couple more remarks but I'll need to verify these before shouting
them out :-)

Cheers.

-- 
 \ Vik /-_-_-_-_-_-_/
  \___/ Heyndrickx /
   \ /-_-_-_-_-_-_/  Knight in the Order of the Unsigned Types