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 Mime-Version: 1.0 To: Nate Eldredge 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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