[hatari-devel] Sign of Fread size parameter
Laurent Sallafranque
laurent.sallafranque at free.fr
Mon Jan 25 22:09:29 CET 2010
It sounfd good to me too.
Shall I commit ?
Laurent
Eero Tamminen a écrit :
> 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.
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>
>
More information about the hatari-devel
mailing list