Sender: vheyndri AT rug DOT ac DOT be Message-Id: <354439F1.7CC2@rug.ac.be> Date: Mon, 27 Apr 1998 09:55:29 +0200 From: Vik Heyndrickx Mime-Version: 1.0 To: Nate Eldredge Cc: djgpp-workers AT delorie DOT com Subject: Re: Far string/mem functions References: <19980427032245 DOT AAD5484 AT ppp100 DOT cartsys DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Nate Eldredge wrote: > I suppose "search" functions could return 0xffffffff if not found, but that > is counterintuitive to the str* model, and is also inconvenient for the user. > > Or we could add an argument that's a pointer to a "found" flag, but that is > ugly too. I don't like 0xffffffff. That is some sort of engineering kind of problem solving. It will eventually lead to some problem. An lword just can contain 2^32 number of different values, not a single one more. The solution I propose to this problem is similar to your second suggestion: Return the status of the search through the return value. When the search was successful return the found position in a variable pointed to by one of the function's arguments. e.g. int _far_memchr (size_t *ret_ofs, short unsigned sel, long unsigned ofs, long unsigned count, char c); Description: The _far_memchr functions searches a far memory region of size ``count'' for the first occurance of the character ``c''. If found, _far_memchr will return 0 and set the value pointed to by ret_ofs to the offset within the string that points to the first ``c''. If not found, _far_memchr will return non-zero and *ret_ofs will remain undefined. I have been using this technique for DOS interface functions for some time now, and it has proven to work reliable. And it can yield consistency. Maybe the order of the parameters needs changes in order to make it consistent with the other functions. -- \ Vik /-_-_-_-_-_-_/ \___/ Heyndrickx / \ /-_-_-_-_-_-_/ Knight in the Order of the Unsigned Types