[hatari-devel] Sign of Fread size parameter (was: Wotanoid problem)
Eero Tamminen
eerot at users.berlios.de
Mon Jan 25 22:02:22 CET 2010
Hi,
On Monday 25 January 2010, Thomas Huth wrote:
> > George just tested that the change was between STE (TOS 1.6 I assume)
> > and Falcon (TOS 4.x I assume). The change may still have happened in
> > TOS 2 or TOS 3. And besides, one can also use EmuTOS with Falcon and
> > that uses signed value. :-)
>
> I just wrote a little test program (am I the only one here with a
> working cross-compiler?),
I guess so...[1]
> that simply executes an Fopen + Fread with
> size 0xffffffff, and it seems like the Fread size parameter is still
> signed in TOS 2.06 and TOS 3.06, but has become unsigned with TOS 4.00.
Great, thanks!
> > Thomas, I think it would be fairly safe to change the value to
> > unsigned. There can't be many programs that rely on operating system
> > calls like this to *fail* when given parameters that are invalid in
> > older TOS versions.
>
> Well, but some old programs might rely on this behaviour - especially
> since the parameter is documented as signed in all major documentation.
>
> I suggest the following fix: Make the Size variable unsigned (e.g.
> Uint32), and add something like the following code right after the
> Gemdos_IsInvalidFileHandle() check in gemdos.c:
>
> /* Old TOS versions treat the Size parameter as signed */
> if (TosVersion < 0x400 && (Size & 0x80000000))
> {
> /* return -1 as original GEMDOS */
> Regs[REG_D0] = -1;
> return true;
> }
>
> What do you think?
Sounds good to me!
> > I would still like it to be pinpointed more accurately in which exact
> > TOS version this behaviour change happened so that we can document it
> > (at least in the source code).
>
> I've also put Gerhard Stoll on CC:, he's the maintainer of the TOS
> hypertext, so it might be interesting for him, too.
- Eero
[1] I don't really need or want a cross-compiler as stuff that I would need
to build is pretty small. What I've wanted to get working is fairly up to
date native Atari toolchain, but the one I had earlier was under MiNT and
I don't have yet recovered/set up a good new working MiNT setup (with all
the Unix stuff) that works also in Hatari. I have gotten distracted by
other issues like Hatari GEMDOS & IDE support, copying files between them,
the Hatari debugger features etc. :-)
Btw. Trying Vincent's native Gcc 4.x under plain EmuTOS without MiNT was
a very good test-case for my GEMDOS emu long file name patch, MiNTlibs do
all kinds of wierd path stuff... Without MiNT & proper Unixy environment
that's not very useful though (EmuTOS want's executables to have ttp/tos/prg
extension and gcc wants to use them without etc).
My next plan is setting up EmuTOS + Gulam + command line tools from AHCC.
I need AHCC also to test the Hatari debugger symbols support.
More information about the hatari-devel
mailing list