Mail Archives: djgpp-workers/1998/04/20/21:26:02
> * Where should their prototypes go? <sys/farptr.h>? <string.h>, 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 <libc/fatptrgs.h>
> 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.
- Raw text -