[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two bugs fixed in ramfs 1.4
> ======================== quote =======================
> You should apply the following patch to ramfs.c to upgrade it from
> version 1.4 to version 1.5. It fixes these two bugs.
> I believe there is another bug. STZIP Fseek's to the end of the
> file to read the header information at the end. STZIP is not able
> to read the header information from any file on RAM FS. I believe
> its a problem of RAMFS.
increasing the debug level in MiNT reveals that stzip issues a
Fseek(-2048,2) on handle 6
which should hopefully put the pointer 2048 bytes before the end of the
file. The problem is of course: should the offset really be negative? I
have two books about Gemdos which give two different answers to this
simple question -- probably Murphy's law.
Most of the device drivers existing for MiNT (procfs.c, shmfs.c,
clockdev.c) assume that Fseek(offset,handle,2) will put the pointer
"offset" bytes _before_ the end of the file. Therefore, "offset" should
be positive. Ramfs also follows this convention. Minixfs probably
follows the opposite convention, since it works with stzip.
[ We could make the program more bomb-proof by considering only the
absolute magnitude of "offset"; but in ramfs you should also be able to
seek past the end of a file, so it's not desirable. ]
Well, lseek in Unix says the offset is added to the specified position
(beginning, current, end), so this would seem to be a pervasive bug.