From: Martin Str|mberg 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 > #include > #include > + #include 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, ®s); > 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, ®s); > 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, ®s); > > ! /* 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, ®s); > ! > ! /* 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