From:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id:	<200012271558.QAA00696@father.ludd.luth.se>
Subject:	Re: Fw: Patch for statfs.c
In-Reply-To:	<3A491B56.63C9CF49@softhome.net> from Laurynas Biveinis at "Dec 26, 2000 11:27:34 pm"
To:	djgpp-workers AT delorie DOT com
Date:	Wed, 27 Dec 2000 16:58:53 +0100 (MET)
Cc:	nbensa AT hotmail DOT com
X-Mailer:	ELM [version 2.4ME+ PL54 (25)]
MIME-Version:	1.0
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

According to Laurynas Biveinis:
> *** src/libc/compat/sys/vfs/statfs.c.~	Mon Jun 19 19:00:56 2000
> --- src/libc/compat/sys/vfs/statfs.c	Mon Dec 25 18:02:18 2000
> ***************
> *** 13,18 ****
> --- 13,19 ----
>   #include <fcntl.h>
>   #include <sys/vfs.h>
>   #include <libc/dosio.h>
> + #include <malloc.h>

Err. malloc.h? Why do yo need that one?
> ***************
> *** 25,42 ****
>     int drive_number;
>     int cdrom_calls_used = 0;
>     long blocks = 0;
> !   long free = 0;
>     long bsize = 0;
>   
>     /* Get the drive number, including the case of magic
>        names like /dev/c/foo.  */
>     _put_path(path);
>     drive_number = (_farpeekb(_dos_ds, __tb) & 0x1f) - 1;
>     if (_farpeekb(_dos_ds, __tb + 1) != ':' || drive_number == -1)
>     {
>       regs.h.ah = 0x19;
>       __dpmi_int(0x21, &regs);
>       drive_number = regs.h.al;
>     }
>   
>     /* For a CD-ROM drive, 213600 gives incorrect info.
> --- 26,46 ----
>     int drive_number;
>     int cdrom_calls_used = 0;
>     long blocks = 0;
> !   long freec = 0;

Why are you needlessly renaming variables?

>     long bsize = 0;
> +   char *curdrive;
>   
>     /* Get the drive number, including the case of magic
>        names like /dev/c/foo.  */
>     _put_path(path);
> +   (const char *)curdrive = path;
>     drive_number = (_farpeekb(_dos_ds, __tb) & 0x1f) - 1;
>     if (_farpeekb(_dos_ds, __tb + 1) != ':' || drive_number == -1)
>     {
>       regs.h.ah = 0x19;
>       __dpmi_int(0x21, &regs);
>       drive_number = regs.h.al;
> + 	curdrive = getcwd (NULL, 256);
>     }

What's the deal with this curdrive? What does it fix?

> --- 138,209 ----
>        && _is_fat32(drive_number + 1) /* Is it a FAT32 drive? */
>          )
>       {
> !       /* First try 217303 as 217302 reports fake free space
> !          (largest block of free clusters?) */

Isn't it better to document the name of the service we call. We do see
that it's INT21, AX=0x7303 from the code. INT21, AX=7302 is ok to
leave as that references code later on, but please be a little less
cryptic.

> !       _put_path (curdrive);
> !       regs.x.ax = 0x7303;
> !       regs.x.ds = regs.x.es = __tb_segment;
> !       regs.x.dx = regs.x.di = __tb_offset;
>         regs.x.cx = 0x100; /* 256 bytes should be enough (RBIL says 0x3f). */
> !       __dpmi_int (0x21, &regs);
>   
> !       /* Errors? (217303 seams to fail under plain DOS) */
> !       if (regs.x.flags & 1)
>         {
> ! 	/* Get free space info from Extended Drive Parameter Block. */
> ! 	regs.x.ax = 0x7302;
> ! 	regs.h.dl = drive_number + 1;
> ! 	regs.x.es = __tb_segment;
> ! 	regs.x.di = __tb_offset;
> ! 	regs.x.cx = 0x100; /* 256 bytes should be enough (RBIL says 0x3f). */
> ! 	__dpmi_int(0x21, &regs);
> !       
> ! 	/* Errors? */
> ! 	if( regs.x.flags & 1 )
> ! 	{
> ! 	  errno = ENODEV;
> ! 	  return( -1 );
> ! 	}
> ! 
> ! 	freec = _farpeekw (_dos_ds, __tb + 0x2 + 0x1f) +
>   	  65536 * _farpeekw (_dos_ds, __tb + 0x2 + 0x21);
>   	bsize = _farpeekw (_dos_ds, __tb + 0x2 + 0x2) *
>   	  ( _farpeekb (_dos_ds, __tb + 0x2 + 0x4) + 1 );
>         
> ! 	blocks = _farpeekl( _dos_ds, __tb + 0x2 + 0x2d) - 1;
>   #if 0
> ! 	printf("Second: bsize = %ld, free = %ld, blocks = %ld.\n"
> ! 	  , bsize
> ! 	  , freec
> ! 	  , blocks
> ! 		);
>   #endif
> +       }
> +       else
> +       {
> + 	freec  = _farpeekl (_dos_ds, __tb + 0x0c);
> + 	bsize  = _farpeekl (_dos_ds, __tb + 0x08)
> + 		* _farpeekl (_dos_ds, __tb + 0x04);
> + 	blocks = _farpeekl (_dos_ds, __tb + 0x10);
> +       }
>       }
>     }

Either I'm misreading something (these non--u patches are hard on me),
but didn't the rescaling disappear? Why? As you had a large drive your
program wouldn't even enter this piece of code (so why did you chopp
it). Or did it (so what were the values of free and blocks in "if(
free < blocks )")?


Right,

						MartinS

- Raw text -