[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fwrite problems and bringing down MiNT
> > I was updating some code recently and accidentally ended up with a
> > negative number of 'bits' of information to write. This had two results
> > when the program was run:
> >
> > 1. (Without Memory Protection) it hit the disk continuously wiping out
> > my minix partition (or was this that I switched off my Falcon while the file
> > was being updated - I don't think so).
>
> This sounds like GEMDOS is passing a negative value for "count" to
> Rwabs.
> This is probably caused by the TOS GEMDOS and should be fixed in both
> TOSFS and the new VFATFS.
He actually mentioned the Minix FS. I think it would be easier to fix that
at the DOS level, something like this:
--- dosfile.c.orig Tue Jun 9 13:28:56 1998
+++ dosfile.c Tue Jun 9 13:32:20 1998
@@ -674,6 +674,11 @@
#endif
proc = curproc;
+ if (count <= 0) {
+ DEBUG(("Fwrite: invalid count: %d", count));
+ return ERANGE;
+ }
+
if (fh < MIN_HANDLE || fh >= MAX_OPEN || 0 == (f = proc->handle[fh])) {
DEBUG(("Fwrite: bad handle: %d", fh));
return EIHNDL;
> > Is this how fwrite should behave? Wouldn't it be better to catch this and
> > return zero bits of information written. Also don't know what happens if
> > fwrite is asked to write zero bits of information.
>
> That should be handled gracefully.
This doesn't make much sense to call Fwrite with a zero count. So
it seems harmless to just return an error.
--
Konrad M.Kokoszkiewicz
|mail: draco@mi.com.pl | Atari Falcon030/TT030/65XE |
|http://www.orient.uw.edu.pl/~conradus/ | ** FreeMiNT development ** |
** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.