http://www.coderscauldron.com/pub/misc/ft.zip

The code given should reproduce the bug, which at the moment seems to be triggered by:

1. Not writing to the start of an (empty?) file when it has just been created
2. Going back and writing to the start, without overlapping the data just written (???)
3. Performing a write just after a read

Have fun.

Do you still want me to check anything? I'll definitely do it tonight, if you need me to - but I'm going home for Easter for two weeks Risc PCless tomorrow...

But it also fixes the same problem which affects g++ 3.0 on linux 2.14.16 (red hat 7.1). That probably doesn't help, other than knowing it's a g++ problem, not a RISC OSy one. But why does UnixLib fix it?

[Edited by monkeyson at 18:22, 20/3/2002]

Can people have a shot at downloading and running (And recompiling on their computer, using different settings) this file:

http://www.coderscauldron.com/pub/misc/fa.zip

In it you should find the following:

DoTest - an obey file to set up and run the test
fileanal - The code to perform the test
source - The C source to fileanal
filedebug - A file containing 'commands' for fileanal to perform

After running DoTest, you should also have the following:
testfile - The test file produced from the commands in filedebug
Log - A file containing a list of discrepencies between testfile and a memory-produced equivalent

A little explanation...

While working on something (*cough* http://www.coderscauldron.com *cough*), I seem to have found a bug in the shared C library's file handling - data being written to an updateable file (opened with 'rb+') was not being written, and trying to read the data returned -1's.

After fiddling round for a while, I got the program containing the bug to write a log file of all the operations it performs ('filedebug'). By compiling the analysis program ('fileanal') using different settings, it should be possible to work out what it is thats causing the problem.

The included copy of fileanal has been compiled against the shared C library (5.17, 3rd Oct 2000) using GCC (2.95.4). Compiling it against unixlib fixes the problems (In both the original program & fileanal), so I'm guessing its either a problem in GCC or the shared C library.

That's where you come in - can anyone with different versions of the shared C library, or different compilers, have a shot at running/compiling the program themselves.

Thanks

The changes you list don't have any effect on RISC OS GCC 2.95.4 & CLib module 5.17. UnixLib doesn't have a problem with any of the settings I've tried.

I suppose that you'll have to try asking on comp.sys.acorn.programmer or the RISC OS GCC mailing list.

Is that a 'I don't understand you' or a 'The bug is on my computer too' ?

I think it was a "Don't shout at me, I like it in the playpen" Frown

Back to the playpen...

Is that a 'I don't understand you' or a 'The bug is on my computer too' ?

I think it was a "Don't shout at me, I like it in the playpen" Frown

Back to the playpen...

Yay! the playpen

[Edited by andypoole at 17:51, 10/3/2002]

Is that a 'I don't understand you' or a 'The bug is on my computer too' ?

I think it was a "Don't shout at me, I like it in the playpen" Frown
Back to the playpen...

Yay! the playpen

Honestly, some people might think you lot were looking for jobs at ROL

I'll have a look for you Monday evening if you want, and post the results Tuesday.

Thanks Moss - at least then I'll know whether it's just me who's going crazy

Honestly, some people might think you lot were looking for jobs at ROL

*runs*