Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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: Sat, 9 May 1998 10:29:59 -0700
Message-ID: <19980509172947.AAF16984@ppp105.cartsys.com>
Precedence: bulk

At 09:27  5/8/1998 +0200, Vik Heyndrickx wrote:
>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.

Okay, I will do that.

>> >_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;
>}

Now why didn't I think of that? (slapping self on forehead) Of course, you
are right.

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

That is a good point. However, I can also see precedents the other way. I
prefer not to think of search functions as going right or wrong; in this
case I think of its return value more as a predicate. (We don't have a case
like `if (isupper(c) == 0)...' This also has some consistency, though in a
somewhat strange way, with the original functions, which return 0 when not
found. For the comparison functions, it makes sense to consider it as a
subtraction, in which case returning 0 on equality makes perfect sense.

Anybody else have other ideas?

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

Though upon thinking about the specific case, I realized that the compiler
must consider the following loop just as infinite:

while ((c = getc(in)) != EOF) putc(c, out);

How is the compiler to know that `getc' will eventually return EOF? How is
it to know that `_farstrchr' will eventually return 1?

I agree it's a cosmetic problem, but not a real one.

Nate Eldredge
nate AT cartsys DOT com