From: mert0407 AT sable DOT ox DOT ac DOT uk (George Foot)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Proble with memory allocation...
Date: 8 May 1997 04:54:57 GMT
Organization: Oxford University, England
Lines: 32
Message-ID: <5krmb1$j3c@news.ox.ac.uk>
References: <336F2F3A DOT 7611 AT iiic DOT ethz DOT ch> <336F8736 DOT 5E43 AT cs DOT com> <3371128B DOT 3E83 AT cs DOT com>
NNTP-Posting-Host: sable.ox.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

John M. Aldrich (fighteer AT cs DOT com) wrote:

: Check out __dpmi_lock_linear_region(); the _go32_dpmi_lock_* functions
: end up calling it.

Presumably they return the value they get from __dpmi_lock_linear_region
then?

: > BTW In the docs for _go32_dpmi_lock_data(), the first line of the
: > description is inaccurate; it's copied from the _go32_dpmi_lock_code()
: > description and says the function locks an area of code (should read
: > `data', I think).

: Probably an omission.  The documentation for the more obscure libc

It's more of a typo; it just says `code' instead of `data' once. Being
pedantic I could come up with any number of errors in the docs (missing
#include files, inconsistency in amount of information given for each
function, ...) :)

: functions seems to be updated less frequently than it should.  If you
: feel like fixing it yourself, you should make the correction to the .txh
: files in djlsr201 and submit a bug report to the DJGPP Bug Tracking
: System.

Hmm, I don't know how to do that, but there's no time like the present to
learn :) I'll look into it. I don't want to submit bug reports the
maintainers aren't interested in, though.

-- 
George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
Merton College, Oxford