Message-Id: <5.0.1.4.0.20001128200658.0347bec0@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 28 Nov 2000 21:00:44 -0500 To: Eli Zaretskii From: "Peter J. Farley III" Subject: Re: Locking fcntl() and flock() patches Cc: djgpp-workers AT delorie DOT com In-Reply-To: References: <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001127210039 DOT 034a5360 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk At 09:14 AM 11/28/00 +0200, Eli Zaretskii wrote: >> Whew! But there sure are a lot of them... > >You wrote a lot of code ;-) Hmm. So I did... ;-) >> say something like "... returns a string describing the ..., similar >> to the way strerror returns a string for values of @code{errno}...". >> Does that sound OK? > >Yes. Done. Or rather, It Shall Be Done. >The text you saw was lifted almost verbatim from an older version of >RBIL. So formatting what's in RBIL v61 should not be a problem. OK, I will check it out. >> Well, this is an exact copy of the code for strerror(), so I guess >> that needs fixing too. > >Yes. Go figure. I have to pick *that* code to copy... ;-) >> struct DOSERROR_STR { >> char *exterror_str; >> char *class_str; >> char *action_str; >> char *locus_str; >> }; > >That's what I had in mind. Is everyone OK with this? As I said, I have no problem changing this to a single function that modifies a passed struct with (char *) members, but is this what we all want? Positive responses, please, even if they are negative. I.E., please RSVP on this, whether you want separate functions or a single one, like dosexterr(). >> if CVS handles this function, I can remove the comment. > >The CVS records a ``checkin comment'', a piece of text, with each >update. It is a usual practice, at least when I commit code >contributed by others, to say there who contributed it. The date of >change, as well as the diffs for the change, are recorded by CVS >automatically. > >My point was that the information about who changed the code and when >is not needed in the source. A person who reads the source might be >interested to know why a particular mapping was taken, but it is >mostly irrelevant who did that and when. Thus, a comment near the >particular mapping which says why it was done is all that is required. > >But if you feel that this comment, as you wrote it, should be >retained, I don't have any strong objections. Ah! I misunderstood. Then, how about just the part of the comment that the value for 21h/33 was changed from EPERM to EACCES for fcntl? Is that more appropriate? >> This is Mark E.'s original code, I did not change it. I can make the >> changes you suggest. > >Unless Mark objects, please do. Waiting to hear from Mark on this, but it seems to me a reasonable change to make. Mark, what do you think? >> Again, this is Mark E.'s code, I have *not* done the research to have >> this knowledge. However, if what you are saying is that the value >> needs to be tested for x'FF' and to return EBADF if equal, that can >> be done. > >Yes, that's what I'm saying. RBIL clearly says that the value of FFh >is an indication of an invalid handle. This is also confirmed by what >I know from other sources: JFT, the table in the program's PSP where >DOS keeps, for each open handle, the index of the corresponding SFT >entry, has an FFh for each unopen handle. DOS only allows for a >maximum of 255 handles per process, from 0 to 254; 255 is left free >for this purpose. That seems a sensible test to put in, then. >It would be interesting to see whether Int 21h/AH=5Ch works with FAT32 >in a way that supports regions and offsets as large as FAT32 can allow >in principle. RBIL is silent on this, as far as I could see. Can >someone please test that, on both DOS and Windows? (Does SHARE.EXE >which comes with DOS 7.10 and later even support FAT32?) > >If large regions can be locked, I think we need to consider changing >the declaration of struct flock accordingly. What trouble can this >make, given that we only widen the types? Do other systems which >support large files [Linux, Solaris] use different structures in fcntl >locking in this case? Well, I think on systems that support large files, type "off_t" is probably a "long long", whatever that means on those systems. As long as the definition of "off_t" is compatible everywhere it is used, there should not be a problem, I would think. It just reinforces the requirement that the programmer use variables of the right type. Right? >> How would one go about determining whether an arbitrary combination >> "covered the whole file"? > >You use lseek to seek to the starting offset, then look at lseek's >return value and compare it with zero. Then you lseek to the end of >the region and compare lseek's return value with the result of >"lseek(fd,0,SEEK_END);". I also assume you meant to say "llseek" there, right? >> And thank you for your diligence in reviewing it all. Forgive me in >> advance if I don't catch everything in pass #2. > >Don't worry, I'm used to it ;-) Hmm. I wonder why? :) --------------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org OR pjfarley AT banet DOT net)