I'd guess it's the program not the libraries.

In fact I'm 100% sure that my code is correct - after all, when the code reads the file while it's being written, it returns -1 for the values (i.e. an error has occured). It can't be an EOF error since it's right near the start of the file, so it must be something else...

In fact I'm 100% sure that my code is correct - after all, when the code reads the file while it's being written, it returns -1 for the values (i.e. an error has occured). It can't be an EOF error since it's right near the start of the file, so it must be something else...

Your program writes unsigned values to the file using fputc and the values in memory are treated as signed values. You'll notice that each pair of values that disagree satisfy the condition

file_value - mem_value = 256

Also your condition isn't true; on my computer the log file lists the following (Complete with half-a**ed attempt to align the text):

FILE MEM POS
 0 172 12
 0 173 13
2 of 42716 incorrect

If you're talking about the -1's filedebug reports as being read, then you're still wrong since fgetc is meant to return an int; 0-255 for a normal value, and -1 (the value of EOF) for an error. Unfortunately C doesn't seem to have any way of reading what that error is, only whether it's there or not. A quick change of the program reveals that when fgetc returns -1, ferror returns that there is an error. Trying to clear the error using clearerr only results in feof saying the end of file's been reached.

Also checking errno doesn't reveal anything useful.

I'll have a look and see whether I can simplify the test a bit.

Although I wouldn't put it past myself to be that stupid, changing the memory copy of the file to store unsigned chars doesn't fix the problem. I also changed it so that 'val', the variable passed to fputc/from fgetc is also an unsigned char, with no effect whatsoever on the output.

fputc should cast the integer to an unsigned char anyway.

Also your condition isn't true; on my computer the log file lists the following (Complete with half-a**ed attempt to align the text):

FILE MEM POS
 0 172 12
 0 173 13
2 of 42716 incorrect

I think we have established that the problem I experience with your code is different to the one that you have. The log file here includes the following:

FILE MEM POS
172 -84 12
164 -92 13
188 -68 16
...
180 -76 42640
188 -68 42644
139 -117 42701
87 of 42716 incorrect

This is using gcc version 2.96 20000731 on a recent Linux setup.

If you're talking about the -1's filedebug reports as being read, then you're still wrong since fgetc is meant to return an int; 0-255 for a normal value, and -1 (the value of EOF) for an error. Unfortunately C doesn't seem to have any way of reading what that error is, only whether it's there or not. A quick change of the program reveals that when fgetc returns -1, ferror returns that there is an error. Trying to clear the error using clearerr only results in feof saying the end of file's been reached.

I think that we are looking at different parts of the code. I wasn't looking at the possibility of EOF being returned, just at the results which were written to the log file.

Now, if I change the declaration

char *mem;

to

unsigned char *mem;

and the assignment

mem = new char[SIZE];

to

mem = new unsigned char[SIZE];

then recompiling and running produces the following log file:

FILE MEM POS
0 of 42716 incorrect

So assuming all went correctly, the problem is solved, on this machine at least.

Now we need to know whether it works as expected on RISC OS using UnixLib and Clib.

I've posted it to their bug tracker anyway. If it gets no response in a week or two then I'll use the mailing list.

It's the checking bit afterwards.

for (num=0;num<fs;num++)
{
val = fgetc(f);
if ((val != mem[num]) && (set[num] != 0))
{
fprintf(stderr, "MONKEYTEST %d != %d\n", val, mem[num]);
}
if (((char)val != mem[num]) && (set[num] != 0)) // THIS MODIFICATION MAKES IT WORK
{
fprintf(log,"%3d %3d %d\n",val,mem[num],num);
pos++;
}
}

fgetc() returns the character as an unsigned char cast to an int. It seems that you have to cast this int back to a char when you do the comparison with mem[num].

The file reading stuff is correct, it's validation that screws up.

cslin221% cat log
FILE MEM POS
0 of 42716 incorrect

There may be some problems in my the file checking code, but the real problem which we are trying to track down/fix is in the shared c library!

The problem seems to be triggered by writing some data just after some has been read (i.e. no fseek inbetween).

The SharedCLibrary will start returning errors from fputc, and will fail to write anything else to the file. Unixlib on the other hand appears to write the first byte, but then fail to write any other bytes (Without returning any errors at all). By writing my own file handling code, I've been able to ascertain that it is a bug in unixlib/the shared c library, and not my program or the filing system.

Tomorrow I'll release some code to demonstrate this.

This is the log file:

File handling log

Machine/program/compiler details:

Compiled on Apr 8 2002 at 17:09:16
GNU C version 2.95.3-5 (cygwin special)

Actions performed:

Action | Data | Memory | C | OK?
----------------------------------
fseek | 1 | 0 | 0 | YES
write | 1 | 1 | 1 | YES
write | 2 | 2 | 2 | YES
fseek | 0 | 0 | 0 | YES
write | 3 | 3 | 3 | YES
fseek | 1 | 0 | 0 | YES
read | ---- | 1 | 1 | YES
write | 4 | 4 | 4 | YES
fseek | 0 | 0 | 0 | YES
write | 5 | 5 | 5 | YES

Check output:

File pos | Memory | C | OK?
------------------------------
0 | 5 | 5 | YES
1 | 1 | 1 | YES
2 | 4 | 2 | NO

Total 1 of 3 wrong

HTH

Well, thanks for the help.

If the bug appears on RISC OS, Linux and Windows then I'd guess it's somehow a bug in GCC. Can someone try compiling it on something other than GCC?

Logfile follows:

File handling log

Machine/program/compiler details:

Compiled on Apr 8 2002 at 18:26:24

Actions performed:

Action | Data | Memory | C | OK?
----------------------------------
fseek | 1 | 0 | 0 | YES
write | 1 | 1 | 1 | YES
write | 2 | 2 | 2 | YES
fseek | 0 | 0 | 0 | YES
write | 3 | 3 | 3 | YES
fseek | 1 | 0 | 0 | YES
read | ---- | 1 | 1 | YES
write | 4 | 4 | -1 | NO
fseek | 0 | 0 | 0 | YES
write | 5 | 5 | -1 | NO

Check output:

File pos | Memory | C | OK?
------------------------------
0 | 5 | 3 | NO
1 | 1 | 1 | YES
2 | 4 | 2 | NO

Total 2 of 3 wrong

Ah, the humor.

The results from lcc are exactly the same as the results from gcc - gcc+clib produces the same results as lcc+clib, and gcc+unixlib produces the same as lcc+unixlib. So apart from there being some glaringly obvious mistake in my code, the only other reason I can think of is that the 'original' version of gcc (Or whatever gcc got the code from) had bugs in its library, which were then copied into every other platform gcc was ported to - it's reasonable to assume that Acorn, Microsoft, etc. all modified the standard GCC libraries to come up with the variants on their own OS's. I'll have a word with the GCC peeps...

With respect, your logic is absolute rubbish.

I can't think of any reason at all that Acorn or MS would be going anywhere near GCC's libraries - either its runtime support, or in the case of RISC OS, Unixlib. Acorn's SharedCLibrary is an _entirely_ different library implementation. Equal comments apply to any MS C version you care to name.

Almost certainly the fault is in your own code - this is very easy to assume given the nature of C

One of the first rules of programming is "the library is not buggy".

Note, I'm not ruling out any possibility; I'm just asking you to first presume the obvious.

Peter

I've pretty much presumed the obvious to death. The fact that some RISC OS file handling code/memory code and the C library code produce different results either means there is some obscure clause in the library meaning my code isn't meant to work, or there is a bug somewhere. As of yet I haven't heard anything from the GCC mailing list. If I can find the time, I'll have a look for some source to a library and poke around in that.

I'm afraid your logic continues to make little sense. I can't do anything but boggle :-|

If, as you say, the fault is in the library (or libraries), then it has absolutely _nothing_ to do with GCC, since it's not a compiler issue. As I've tried to explain in my previous message, the library is a completely different entity to the compiler. As such, you're not going to get any sympathy from any GCC list (except maybe the RISC OS one, but you haven't joined that).

Peter, boggled.

While looking through the PRMs last night, I noticed the following:

When a file is opened with update mode (+ as the second or third character in the mode argument), both input and output must be performed on the associated stream. However, output must not be directly followed by input without an intervening call to the fflush function or to a file positioning function (fseek, fsetpos, or rewind), nor may input be directly followed by output without an intervening call to the fflush function or to a file positioning function, unless the operation encounters end-of-file.

I hate ANSI. I really do

I'm still fiddling round with it now, just creating a nice platform independent file. I'll include your two logfiles, as well as other bits of info I've collected.

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