Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <353C5DE9.6CCB@rug.ac.be>
Date: Tue, 21 Apr 1998 10:50:49 +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
References: <19980421011110 DOT AAH9311 AT ppp124 DOT cartsys DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Nate Eldredge wrote:

I've been writing similar functions, so I'm kinda interested :)
While writing these functions I ran into several problems, which are
difficult to solve without getting a NO from d-w. Since there were too
many NO's I abandoned the idea.
Below, you find some of my recommandations and hopefully some answers.
 
> * Does it seem necessary to document them completely, or can we just list
> their prototypes and refer users to the corresponding near functions? They
> are very similar; the only differences are that each pointer arg to the
> original is replaced by two unsigned args (selector and offset) in the far
> versions. Functions that returned pointers return the offset only.

There are two different kind of such pointer returns:
1. The ones that are actually useful such as a matching position for
e.g. memchr.
2. The ones that return one of there arguments, like memcpy.

In the first case returning the offset seems fine at first, however what
do you return to the user in case the original function returns NULL? 0
won't do the job.
In the latter case returning anything is quite useless because
simulating the original behaviour exactly is impossible and therefore I
would return nothing at all.

I plea strongly for type-correctness:
  selectors are 'short unsigned int'
  offsets are 'long unsigned int' (the same type as size_t)

The gain from using unsigned for the selector instead is so marginal and
the potential number problems that may arise relatively so large that
'short unsigned' is the best choice.

> * As written currently, my `_farmemcmp' may (for efficiency) touch memory
> beyond the first byte mismatch, though not beyond the given limit. Is that
> legal?

Even touching memory beyond the given limit (were speaking here about 3
bytes at most, right?) would be acceptable, I think.

> Current status:
> * I have written all the functions I plan to, though I have NOT yet tested
> them at all.

I volunteer...

> * Many of the functions are very inefficient (`_farstrcasecmp', for
> instance, does a segment register load for each character). Yes, I'm lazy.

That's really BAD ;-)

> * I have not written a makefile nor any documentation.

I don't volunteer :-)

> I will post them here (or would it be better to upload to delorie.com? It's
> about 16K altogether right now) when they are more stable, and when I can
> integrate them into the libc.

If you could send me a copy... or an URL...

BTW, recently, I sent DJ a new asm version of memmove which can easily
be tweaked to do also far memmove's. That routine also supports a
generally faster non-inlined memcpy. I hope DJ will put it in the next
alpha release.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/