Hi!
2-Апр-2004 11:41 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> - bug: blockio.c/AllocateHMASpace(): wrongly freed extra buffer because
>> "FP_OFF(bp+1) >= lowbuffer" expression (should be ">").
BO> If your patch would just correct this
Yes, it fixes also this:
______________O\_/_________________________________\_/O______________
- if (FP_OFF(bp) < highbuffer && FP_OFF(bp+1) >= lowbuffer)
+ ofs_t next = b_(buf)->b_next;
+
+ /* check if buffer intersects with requested area */
+ if (buf < nextarea && buf + sizeof(struct buffer) > startarea)
_____________________________________________________________________
O/~\ /~\O
I found this bug because when I test allocating memory, I detect extra
buffer dellocation. (I wrote small program, which lists address of buffers
in chain).
BO> I would apply it straight away.
BO> But sorry, there's too much extra stuff in there (sigh.. didn't I
BO> write this before, what's the point...)
Yes, beside bugfix in blockio.c function AllocateHMASpace() was renamed
to freeHMAbuffers() (this function not mentioned in headers, only with
"extern" directly in inthndlr.c) and optimized (instead full far pointers
used only offsets).
>> In next letter I present patches, which will fix all of these bugs and
>> inconsistencies, also as reduce kernel size after BC: in memory by 176
>> bytes, unpacked executable by 182 bytes.
BO> Sorry, I don't care about BC memory size.
I not test yet under OW, only under BC.
BO> I'm not going to replace
BO> b_prev(bp)->b_next = bp->b_next;
BO> b_next(bp)->b_prev = bp->b_prev;
BO> by
BO> b_(b_(next)->b_prev = b_(buf)->b_prev)->b_next = next;
BO> just to reduce that. Maybe, if it has a similar effect on OW I will think
BO> again. Fair OW memory size reductions are welcome.
Later I may check how much memory reduced under OW, if you don't check
this yourself.
BO> But your blockio.c
BO> changes only save 8 bytes (13 bytes without the 0xffff check)
BO> I can save 21 bytes without the 0xffff check by simply applying.
This check is required: firstAvailableBuf (which should be named
HMAuserspace) with my patch points to HMA even if buffers are in low memory:
______________O\_/_________________________________\_/O______________
-
- {
- size_t bytes = sizeof(struct buffer) * anzBuffers;
- pbuffer = HMAalloc(bytes);
- if (pbuffer == NULL)
+ {
+ size_t bytes = sizeof (struct buffer) * buffers;
+ if ((pbuffer = HMAalloc(bytes)) == NULL)
{
pbuffer = KernelAlloc(bytes, 'B', 0);
+ if (HMAState == HMA_DONE)
+ firstAvailableBuf = MK_FP (/*HMASEG*/0xFFFF, HMAFree);
_____________________________________________________________________
O/~\ /~\O
BO> It's also pointless to replace ofs_t by size_t.
This is just for clarification: size_t for sizes, ofs_t for offsets,
seg_t for segments. This should make sources more readable.
BO> Since converting a pointer to an integer in C gives a size_t,
"(int)ptr" converts to "int", not to size_t. Or I wrongly understand
this your sentence?
BO> it can't be any different than your ofs_t. Sure, the huge model is
BO> different but that doesn't count, since compiling the kernel using that
BO> would break a lot more.
size_t in huge model remains same, as in all other models - ie. 16-bit
unsigned integer.
BO> I've been thinking of using ofs_t for file offsets (unsigned long)
BO> though...
:( Why not name file offset type consequently? Say, "fileofs_t"?
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
