Mime-Version:	1.0
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
From:	Nate Eldredge <nate AT cartsys DOT com>
Subject:	Re: Far string/mem functions available for testing
Cc:	djgpp-workers AT delorie DOT com
Date:	Thu, 7 May 1998 17:53:27 -0700
Message-ID:	<19980508005312.AAD26907@ppp117.cartsys.com>

At 11:23  5/7/1998 +0200, Vik Heyndrickx wrote:
>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

I had it that way at first, then changed it.  I think I was wondering, since
selectors are now `unsigned short', whether the garbage that the high half
of the longword would contain could cause a problem. If not, I will change
it back.

>When pointer to result is NULL -> should yield undefined behaviour
>(meaning: libc functions shouldn't test it).

I thought it might be convenient if a person who didn't care where the
string was found, but only if it was there, could avoid creating a dummy
variable.

>Count parameter should always have have type size_t (function
>_farmemcpy).

Thanks. That was indeed a bug.

>typedef for seg and ofs seems a good idea.

I'm not sure if that's a suggestion or a comment. They *are* typedef'd.

>``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 ;-)

I seem to recall from looking at some glibc sources that on newer
processors, Intel had put more work into speeding up the more RISC-ish
instructions than the string ones. The result was that they could sometimes
be slower than their simpleminded equivalents. I don't know enough to know
whether that applies here, hence the comment. But you may well be right.

>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.

True. However, the other option is to do something like:

_farsetsel(sel);
while ((cc = _farnspeekb(ofs++)) != c && cc != '\0') ;

I thought the gain over this by being able to use block search functions
would offset the expense of scanning the extra bytes, but I can see that is
not the case when n is large.  Hmm.

>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

Good point. Not that I ever expect anyone to use `_farstrdup'... :)

>_farstrcat contains a bug.

You are right. Silly oversight on my part. Fixed now.

I didn't see it at first, because I neglected to have the test program ever
call the `_farstrcat' test!

>_farstrcspn seem to contain a loop that may never end. At least that is
>how I would think when I were a compiler.

It's true, but I can't think of a better way to write it. Other than
something horribly inefficient and useless like using a `long long' counter
and aborting when it passes 2^32...

GCC has no problem with it, at least not as far as v. 2.7.2.1.

>_farstrrchr may not work with an ofs = 0.

Thanks. Fixed it.

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

Great. I appreciate it.

I will update the version on my web site. I'd rather not go to the trouble
to create patches, unless someone really wants them.

Btw, can somebody tell me the following about LFN's:
* Is case significant with LFN's enabled? i.e. will open("FooBar") fail if
the file is really `foobar'?
* If so, is there a way to make Info-Zip store names as what you tell it,
instead of the actual file names?

I ask because my distribution includes some .S files, and GCC interprets
that differently from .s, and I only have SFNs. Previously I made the zip on
Linux, but rebooting all the time is a pain. For paranoia I am now including
a fixlfn.bat file which will rename them to the appropriate cases, but if
there is a better solution I would like to know it.  (I'm also considering
just naming them .s, and passing GCC `-x assembler-with-cpp', but that's not
pretty.)

Thanks again

Nate Eldredge
nate AT cartsys DOT com

- Raw text -