Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<3552B3DB.132C@rug.ac.be>
Date:	Fri, 08 May 1998 09:27:23 +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:	<19980508005312 DOT AAD26907 AT ppp117 DOT cartsys DOT com>

Nate Eldredge wrote:
> 
> 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.
> >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.

The Intel instruction manual tells that the operand size prefix does NOT
influence the MOV seg,rm and MOV rm,seg instructions. Since I don't
believe manuals like all of us, I tested that, and the manuals are
right. The same, more or less applies to the PUSH/POP instructions but
the word size on the stack is influenced. For USE32 segments like ours
that means that without an operand size prefix (0x66) 4 bytes are used
by push and pop (consider the MSW as being undefined on read).
So changing back the situation would be fine.

> >When pointer to result is NULL -> should yield undefined behaviour
> 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.

Hmm. I can't really give a con-argument, but I don't get a good feeling
about it :(

> >    strcpy (d, s);
> >    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'... :)

You might be surprised:
fileinfo->name = _farstrdup (__tb_sel, __tb_ofs + 0x20);

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

I wasn't accurate about what really was wrong, but the following seems a
slightly better way of writing it:

...
  do {
      r = _farstrchr(&p, str_sel, str_ofs, _farpeekb(set_sel,
set_ofs++));
  } while (r == 0);
  return p;
}

BTW I strongly vote for a return value of 0 being ``it has been found''
or ``they are equal'' and non-0 for ``it has not been found'' and ``they
are not equal''. It may seem a little counter-intuitive, but what I
always say: there is only one way how something can go right, but there
are many ways how something can go wrong. Please think about it in a
broader perspective (a hint: ``errno''). Note that until now I don't
know whether many people share this idea.

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

I don't know for 2.8.1 but in general it has become more intelligent as
concerned the production of warnings. (and I just can help myself being
glad that my programs compile without a warning when compiled with -Wall
-W).

That'll be it for now, so long.

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

- Raw text -