Date: Mon, 20 Apr 1998 21:25:55 -0400 (EDT) Message-Id: <199804210125.VAA27568@delorie.com> From: DJ Delorie To: nate AT cartsys DOT com CC: djgpp-workers AT delorie DOT com In-reply-to: <19980421011110.AAH9311@ppp124.cartsys.com> (message from Nate Eldredge on Mon, 20 Apr 1998 18:11:33 -0700) Subject: Re: Far string/mem functions Precedence: bulk > * Where should their prototypes go? ? , if > not -ansi? A new header? Their prototypes should go in the same headers as the functions they mimic, in the non-ansi/non-posix section. > * Does it seem necessary to document them completely, or can we just > list their prototypes and refer users to the corresponding near > functions? They are very similar; the only differences are that each > pointer arg to the original is replaced by two unsigned args > (selector and offset) in the far versions. Functions that returned > pointers return the offset only. They should be documented completely, but they may contain a "works like @xref" phrase if that documentation may be used. Documentation for such functions should be careful to note potential problems and provide examples that are meaningful for far pointers in djgpp. > * As written currently, my `_farmemcmp' may (for efficiency) touch > memory beyond the first byte mismatch, though not beyond the given > limit. Is that legal? If a function fails because a user (the program) passed an invalid limit (i.e. represented memory that's invalid to use), that's the user's problem. If your functions go beyond the user-specified limit, that's your problem. > * Is it acceptable for a libc function to clobber %gs? libc uses %gs all over the place; see > I will post them here (or would it be better to upload to > delorie.com? It's about 16K altogether right now) when they are more > stable, and when I can integrate them into the libc. ftp.delorie.com would be better, or if you can put it on your ISP's web server.