Re: [Freedos-kernel] LF written to the file being read?

[Bart Oldeman]

On Mon, 22 Mar 2004, Luchezar Georgiev wrote:

> >> But what if it was the first entry in the root directory? Then the
> >> "new_diroff++" in dir_read() will make it -1!
> >
> > remove_lfn_entries() checks for fnp->f_diroff == 0. The first entry can't
> > have any LFN entries connected to it.
>
> Of course! I should have seen that. This is so for lfn_dir_read() too.
>
> I wanted to ask you one more question: chario.c:read_line_handle() calls
> echo_char(LF, sft_idx) - doesn't this write the LF to the file being read?

It writes LF (and any other echo) to the input indeed. But this input can
only be a device with the SFT_CONIN bit set; see dosfns.c. For normal
files read_line_handle isn't called.

This is a difference between int21/a and int21/3f; if you redirect stdout
but leave stdin at the keyboard then the int21/a echo goes into the output
file but the int21/3f output is echoed to the screen.

Bart



---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[Bart Oldeman]

On Mon, 22 Mar 2004, tom ehlert wrote:

> AVB> (BTW, is "protection"
> AVB> from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
> AVB> worth of code?)
> a working kernel is worth a lot of code (even if you don't see the
> reason immediately)
>
> HANDS OFF THE KERNEL, please.

in the end it was just easier to remove add_far() and use
buffer = adjust_far(buffer + offset).

The only users are dsk.c and fatfs.c, where this is safe as long as you
normalize the pointer before the loop.

Which it was in fatfs.c but not in dsk.c.

For the HMA. Yes, hands off: we do often read things (indirectly) into
the HMA, there are BUFFERs there for instance.

Maybe, just maybe, we're safe now with removing HMA logic from adjust_far()
-- but it's way too easy to break this and will lead to bugs that are hard
to solve.

The current CVS kernel now has a 450 bytes smaller HMA_TEXT than ke2033 :)

Bart



---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.42,1.43 fatfs.c,1.56,1.57

[Arkady V.Belousov]

Hi!

22-Мар-2004 16:56 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:

BO> +++ fatfs.c 22 Mar 2004 16:56:33 -  1.57
BO> +xfr_cnt = count < (ULONG) secsize - boff ?
BO> +(UWORD) count : secsize - boff;

 I not check this, but, probably, better if there will no cast to ULONG?
Or, even so:

xfr_cnt = secsize - boff;
if (xfr_cnt > count)
xfr_cnt = (UWORD)count;

BO>  /* get a buffer to store the block in */
BO> +if ((boff == 0) && (xfr_cnt == secsize))

 This condition may be simplified (because previous computation for
xfr_cnt, it may be equal to secsize only when boff==0):

if (xfr_cnt == secsize)

BO>  /* set a block to zero  */
BO> +fmemset((BYTE FAR *) & bp->b_buffer[boff], 0, xfr_cnt);

 Casting here is unneed - see definition for buffer.h/buffer::b_buffer
and other calls to fmem*(...b_buffer...):

fmemset (bp->b_buffer + boff, 0, xfr_cnt);

BO> +  sectors_to_xfer = fnp->f_dpb->dpb_clsmask + 1 - sector;
BO>sectors_to_xfer = min(sectors_to_xfer, sectors_wanted);

 Why not as next?

  sectors_to_xfer = fnp->f_dpb->dpb_clsmask + 1 - sector;
  if (sectors_to_xfer > sectors_wanted)
  sectors_to_xfer = sectors_wanted;

BO> +xfr_cnt = min(to_xfer, secsize - boff);

 Especially, min() with expression isn't good idea. Why not as next?

xfr_cnt = secsize - boff;
if (xfr_cnt > to_xfer)
xfr_cnt = to_xfer;

BO> +  fmemcpy(&bp->b_buffer[boff], buffer, xfr_cnt);

 As above:

  fmemcpy (bp->b_buffer + boff, buffer, xfr_cnt);




---
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

[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.41,1.42 fatfs.c,1.54,1.55

[Arkady V.Belousov]

Hi!

22-Мар-2004 15:43 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:

BO> +  /* can't have more than 65535 directory entries
BO> + remove lfn entries may call us with new_diroff == -1
BO> + for root directories though */
BO> +  if (!fnp->f_flags.f_droot && new_diroff >= 65535U)
BO> +  return DE_SEEK;

 I think, better to swap checks (this may slightly speedup code for
usual cases). Also, I think, this comment should be slightly polished: I
understand it only after reading another message to Lucho with explanation.




---
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

Re: [Freedos-kernel] LF written to the file being read?

[Luchezar Georgiev]

But what if it was the first entry in the root directory? Then the
"new_diroff++" in dir_read() will make it -1!
remove_lfn_entries() checks for fnp->f_diroff == 0. The first entry can't
have any LFN entries connected to it.
Of course! I should have seen that. This is so for lfn_dir_read() too.

I wanted to ask you one more question: chario.c:read_line_handle() calls 
echo_char(LF, sft_idx) - doesn't this write the LF to the file being read?

Thanks for the 240 more low memory bytes, by the way! ;-)

Lucho

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[Arkady V.Belousov]

Hi!

22-Мар-2004 17:57 [EMAIL PROTECTED] (tom ehlert) wrote to "Arkady V.Belousov"
<[EMAIL PROTECTED]>:

AVB>>  Then rename "add_far" into "normalize_ptr" and remove misleading.
te> noone is going to rename functions because you don't like the names.

 "I, as typical programmer" :) say, that there is misleading (which
causes wrong understanding when reading source). In other "add_far" is _not_
"don't liked" me.

AVB>> Also, I may offer next code to always perform normalization:
te> It's there for some specific purpose.

 Bart does better - he removes add_far and reuses adjust_far. :)




---
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

Re: [Freedos-kernel] Re: Last change introduced an "unknown unit" bug

[Bart Oldeman]

On Mon, 22 Mar 2004, Luchezar Georgiev wrote:

> But what if it was the first entry in the root directory? Then the
> "new_diroff++" in dir_read() will make it -1!

remove_lfn_entries() checks for fnp->f_diroff == 0. The first entry can't
have any LFN entries connected to it.

Bart





---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[tom ehlert]

Hello Arkady,

AVB>  Then rename "add_far" into "normalize_ptr" and remove misleading.
noone is going to rename functions because you don't like the names.

AVB> Also,
AVB> I may offer next code to always perform normalization:
It's there for some specific purpose.

AVB> (BTW, is "protection"
AVB> from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
AVB> worth of code?)
a working kernel is worth a lot of code (even if you don't see the
reason immediately)

HANDS OFF THE KERNEL, please.

tom





---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: Last change introduced an "unknown unit" bug

[Luchezar Georgiev]

should be fixed now. remove_lfn_entries() calls dir_read with the offset
== -1 which is not possible for normal directories (. and ..) but is
possible for root directories. So the 65535 check only needs to be 
applied
to non-root directories; the real limit for root directories is checked
somewhere further down the line.
Thanks! I'm going to test this now.
Now the bug went away!

I too just noticed the "fnp->f_diroff -= 2" subtraction in 
remove_lfn_entries() but was going to fix it, not dir_read(). Now I see 
that not only it but also lfn_dir_read() does "fnp->f_diroff -= 2" 
before calling dir_read(), so your fix it better. But please add 
lfn_dir_read() to the comment before the new check or generalise it if 
you like.
But what if it was the first entry in the root directory? Then the 
"new_diroff++" in dir_read() will make it -1!

Lucho

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: Last change introduced an "unknown unit" bug

[Luchezar Georgiev]

should be fixed now. remove_lfn_entries() calls dir_read with the offset
== -1 which is not possible for normal directories (. and ..) but is
possible for root directories. So the 65535 check only needs to be 
applied
to non-root directories; the real limit for root directories is checked
somewhere further down the line.
Thanks! I'm going to test this now. I too just noticed the "fnp->f_diroff 
-= 2" subtraction in remove_lfn_entries() but was going to fix it, not 
dir_read(). Now I see that not only it but also lfn_dir_read() does 
"fnp->f_diroff -= 2" before calling dir_read(), so your fix it better. But 
please add lfn_dir_read() to the comment before the new check or 
generalise it if you like.

Lucho

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Last change introduced an "unknown unit" delete bug

[Luchezar Georgiev]

Bart, unfortunately your very last change (scaling and shortening the 
directory entry pointer) introduced a bug! When I start my "elvis" 
editor (a "vi" clone) and exit it, it can't delete its temporary file 
"ELV_3E5.1"  from my XMSDSK RAM disk where is my temporary directory. 
4DOS fails to delete it saying "4DOS: (Sys) Bad disk unit ":\elv_3e5.1". 
When I test this with "rm" in STEPDOS I see that the UNLINK (delete 
file) DOS function (41h) fails with return code of 14h ("unknown unit") 
which isn't even allowed for it and is an Int 24h error! What's going on 
here?
A slight detailisation. This error is returned on attempt to rename the 
file or delete it. But all reads on it succeed. So, it must be happening 
only on directory writes. Besides, I may be wrong that this bug was 
introduced by your very last changes, because I haven't checked the 
contents of my drive "I:" for a while (probably a couple of days). So it 
may be a result of a slightly earlier change, but in all cases it's a very 
recent change.

Lucho

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[Arkady V.Belousov]

Hi!

22-Мар-2004 14:23 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:

BO> add_far is only used at a few select places where we want to have the
BO> offset part as low as possible. Nothing to do with structures but
BO> everything to do with potentially large file reads, with "read chunk,
BO> update pointer" loops.
BO> Quite possibly Arkady's approach minimizing normalizations has merit but
BO> then each add_far caller needs to be checked if it needs to manually
BO> normalize the pointer afterwards.

 Then rename "add_far" into "normalize_ptr" and remove misleading. Also,
I may offer next code to always perform normalization: (BTW, is "protection"
from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
worth of code?)

void FAR *normalize_ptr (void FAR *fp, unsigned add)
{
  unsigned ofs = add + FP_OFF (fp);
  seg/*_t*/ s = FP_SEG (fp);
  if (ofs < FP_OFF (fp))/* arithmetic overflow? */
s += 0x1000;/* add carry */
  return MK_FP ((ofs >> 4) + s, 0xF & ofs);
}

BO> But for now, because it's not called very often, the time it takes is very
BO> small in comparison with the BIOS calls following, and normalization doesn't
BO> hurt, I haven't changed it.




---
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

Re: [Freedos-kernel] Re: Last change introduced an "unknown unit" delete bug

[Bart Oldeman]

On Mon, 22 Mar 2004, Luchezar Georgiev wrote:

> > ":\elv_3e5.1"
> I mean "i:\elv_3e5.1"
> Sorry for my typo!

should be fixed now. remove_lfn_entries() calls dir_read with the offset
== -1 which is not possible for normal directories (. and ..) but is
possible for root directories. So the 65535 check only needs to be applied
to non-root directories; the real limit for root directories is checked
somewhere further down the line.

Bart



---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Re: Last change introduced an "unknown unit" delete bug

[Luchezar Georgiev]

":\elv_3e5.1"
I mean "i:\elv_3e5.1"
Sorry for my typo!
---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Last change introduced an "unknown unit" delete bug

[Luchezar Georgiev]

Bart, unfortunately your very last change (scaling and shortening the 
directory entry pointer) introduced a bug! When I start my "elvis" editor 
(a "vi" clone) and exit it, it can't delete its temporary file "ELV_3E5.1" 
from my XMSDSK RAM disk where is my temporary directory. 4DOS fails to 
delete it saying "4DOS: (Sys) Bad disk unit ":\elv_3e5.1". When I test 
this with "rm" in STEPDOS I see that the UNLINK (delete file) DOS function 
(41h) fails with return code of 14h ("unknown unit") which isn't even 
allowed for it and is an Int 24h error! What's going on here?

Lucho

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.40,1.41 etc

[Bart Oldeman]

On Mon, 22 Mar 2004, Luchezar Georgiev wrote:

> On Mon, 22 Mar 2004 10:29:28 +, Bart Oldeman wrote:
>
> > Make f_diroff an entry offset so it can be 16bits. Enforce the 65536
> > entry limit in dir_read(). Saves 80 bytes or so + 2 bytes in every
> > f_node.
>
> Great! Saves 112 bytes of LOW memory for my FILESHIGH=58!

I'll save you another 224 bytes soon... f_boff and f_sector aren't
necessary to keep resident. More savings (eliminating f_back,
transforming (f_dirstart (4 bytes),f_diroff (2 bytes)) into (f_sector (4
bytes), f_diroff (1 byte), and maybe even using SFT's to store resident
info) are more complicated.

> > if (new_diroff == 65535)
>
> Borland C++ complains here. Change the constant to 65535UL (see patch
> below).

ok, I'll make it 65535U then, or maybe 0x. Then the U is not
necessary.

Bart




---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] bootfix 1.4

[Arkady V.Belousov]

Hi!

 With help of Michael Devore, on his site placed version 1.4 of BOOTFIX.
This version is now compilable both by Borland C and OpenWatcom. It shows
slightly more information (to ease using logs even without dumps), before
reading BPB added reseting disk (look like this is sometime required for
FreeDOS, when applied to removable media) and there are other minor changes.
Thanks for Jim Lilly for his long efforts in testing bootfix in different
environments.

 Place is usual: .

 In next edition may/should be added possibility to check boot sector
inside files-disk images, then may be added possibility to fix some minor
inconsistencies in boot record (like undefined geometry fields or nonzero
root_entries field).

PS: Looks like Jim Hall also mirrors bootfix utility on ibiblio:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/disk/
Jim, when (and if) you mirror version 1.4, please, notify me. Also, please,
remove older versions (bootfix1 and bootf12), because they are preliminary
editions.




---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[Bart Oldeman]

On Mon, 22 Mar 2004, Eric Auer wrote:

> Hi, about add_far() pointer normalization: I think it would be
> better to normalize earlier. If you have a pointer, you normally
> have a pointer to a STRUCTURE. If the end of the structure ends
> up with an offset > 0x then having the POINTER normalized is
> not enough. So how do you check the SIZE of the structure for
> which you normalize the pointer? Or do you just have an hardcoded
> constant "maximum structure size" for structures for which the
> add_far function can be used?

add_far is only used at a few select places where we want to have the
offset part as low as possible. Nothing to do with structures but
everything to do with potentially large file reads, with "read chunk,
update pointer" loops.

Quite possibly Arkady's approach minimizing normalizations has merit but
then each add_far caller needs to be checked if it needs to manually
normalize the pointer afterwards.

But for now, because it's not called very often, the time it takes is very
small in comparison with the BIOS calls following, and normalization doesn't
hurt, I haven't changed it.

Bart



---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.40,1.41 etc

[Arkady V.Belousov]

Hi!

22-Мар-2004 14:47 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to FreeDOS-kernel
<[EMAIL PROTECTED]>:

>>> if (new_diroff == 65535)
>> Borland C++ complains here. Change the constant to 65535UL (see patch
>> below).

 Hm, don't see letter with these words.

LG> Although Borland says "constant is long", it's enough to change it to
LG> 65535U, not UL.

 Or 0x - as rightly noted by Bart, numeric literals with 0x prefix
default are unsigned.




---
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

[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.40,1.41 etc

[Luchezar Georgiev]

On Mon, 22 Mar 2004 10:29:28 +, Bart Oldeman wrote:

Make f_diroff an entry offset so it can be 16bits. Enforce the 65536 
entry limit in dir_read(). Saves 80 bytes or so + 2 bytes in every 
f_node.
Great! Saves 112 bytes of LOW memory for my FILESHIGH=58!

if (new_diroff == 65535)
Borland C++ complains here. Change the constant to 65535UL (see patch 
below).

Lucho

diff -ruN cvs/kernel/kernel/fatdir.c src/kernel/kernel/fatdir.c
--- cvs/kernel/kernel/fatdir.c  2004-03-22 14:45:54.0 +0200
+++ src/kernel/kernel/fatdir.c  2004-03-22 14:49:00.0 +0200
@@ -213,7 +213,7 @@
   unsigned new_diroff = fnp->f_diroff;
   /* can't have more than 65535 directory entries */
-  if (new_diroff == 65535)
+  if (new_diroff == 65535UL)
 return DE_SEEK;
   /* Directories need to point to their current offset, not for   */

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28

[Eric Auer]

Hi, about add_far() pointer normalization: I think it would be
better to normalize earlier. If you have a pointer, you normally
have a pointer to a STRUCTURE. If the end of the structure ends
up with an offset > 0x then having the POINTER normalized is
not enough. So how do you check the SIZE of the structure for
which you normalize the pointer? Or do you just have an hardcoded
constant "maximum structure size" for structures for which the
add_far function can be used?

Eric.


---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel fatdir.c,1.40,1.41 etc

[Luchezar Georgiev]

if (new_diroff == 65535)
Borland C++ complains here. Change the constant to 65535UL (see patch 
below).
Although Borland says "constant is long", it's enough to change it to 
65535U, not UL.

Lucho

diff -ruN cvs/kernel/kernel/fatdir.c src/kernel/kernel/fatdir.c
--- cvs/kernel/kernel/fatdir.c  2004-03-22 14:45:54.0 +0200
+++ src/kernel/kernel/fatdir.c  2004-03-22 14:49:00.0 +0200
@@ -213,7 +213,7 @@
   unsigned new_diroff = fnp->f_diroff;
   /* can't have more than 65535 directory entries */
-  if (new_diroff == 65535)
+  if (new_diroff == 65535U)
 return DE_SEEK;
   /* Directories need to point to their current offset, not for   */

---
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_id=1470&alloc_id=3638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel