Mail Archives: djgpp-workers/2000/11/28/21:00:30
At 09:14 AM 11/28/00 +0200, Eli Zaretskii wrote:
<Snipped>
>> Whew! But there sure are a lot of them...
>
>You wrote a lot of code ;-)
Hmm. So I did... ;-)
<Snipped>
>> 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.
<Snipped>
>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.
<Snipped>
>> 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... ;-)
<Snipped>
>> 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().
<Snipped>
>> 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?
<Snipped>
>> 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?
<Snipped>
>> 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.
<Snipped>
>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?
<Snipped>
>> 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)
- Raw text -