Thread: Loop Control 'while(!feof(cfPtr))', Duplication of record problem

To add...

- fread/fwrite require the file to be opened in binary mode.

- This:
>>while ((c = fgetc(cfPtr)) != EOF)
>>{
>> fread(&new_cust,sizeof(struct customer),1,cfPtr);
is a problem. Use the return code from the fread to determine when you have reached the end of the file.

>- fread/fwrite require the file to be opened in binary mode.
Since when? The C standard says nothing about the open mode for the stream passed to fread/fwrite and since they are basically wrappers that call fgetc/fputc size times for each object, it makes no sense to have such a restriction.

-Prelude

Originally posted by Prelude
>- fread/fwrite require the file to be opened in binary mode.

Since when? The C standard says nothing about the open mode for the stream passed to fread/fwrite and since they are basically wrappers that call fgetc/fputc size times for each object, it makes no sense to have such a restriction.

-Prelude

Maybe he was really tired. Or perhaps, he was on the phone.

On a side note, I believe that currently the "b" attributes are just hold overs for compatibility with old compilers, and they don't really have any real use any more. IIRC, I remember reading that they've been depreciated in the standard to the point where they don't do anything any more. IE: Text and binary modes are identical. I'll see if I can find a reference unless someone wants to point it out ahead of time.

Quzah.

Originally posted by Codeplug
Text and binary modes definately aren't identical on DOS and Windows machines.

gg

Prove it. I'm on a windows box here. I have MSVC++. The following produces the exact same file:

Code:

#include<stdio.h>
#include<stdlib.h>
int main( void )
{
	FILE * fpt = fopen( "blah.txt", "w" );
	FILE * fpb = fopen( "blah.dat", "wb" );
	struct foo {
		signed char buf[BUFSIZ];
		unsigned short int x;
	} bar = { "blah blah blah blah blah", 12345 };
	if( fpt == NULL || fpb == NULL )
		exit( 0 );
	fwrite( &bar, sizeof( struct foo ), 1, fpt );
	fwrite( &bar, sizeof( struct foo ), 1, fpb );
	fwrite( &bar, sizeof( struct foo ), 1, fpt );
	fwrite( &bar, sizeof( struct foo ), 1, fpb );
	fwrite( &bar, sizeof( struct foo ), 1, fpt );
	fwrite( &bar, sizeof( struct foo ), 1, fpb );

	printf("Fweee...");

	fclose( fpt );
	fclose( fpb );
	return 0;
}

blah.txt:

1.50KB (1,542 byts), 4,096 bytes on disk

blah.dat:
1.50KB (1,542 byts), 4,096 bytes on disk

So again, exactly how are they different? Bytes are bytes. You can write a 't' in text mode, or a 116 decimal value, open both in a text editor, and they'll turn out identical.

[edit]chaning "text file" to "text editor"[/edit]

Quzah.

>Prove it.

Code:

/* ... */bar = { "blah\nblah\nblah\nblah\nblah", 12345 };

With newlines in the text, I see a difference (Windows).

Code:

C:\Projects\Toolkit\stdc\test>"Test.exe"
Fweee...
C:\Projects\Toolkit\stdc\test>dir blah.*
03/21/2003  11:35p               1,554 blah.txt
03/21/2003  11:35p               1,542 blah.dat

The difference you encounter is the operating automaticly inserting '\r' for every newline. Macintosh computers do not use '\n', IIRC, and only use '\r'. *NIX system only use '\n'. Windows use pairs.

The difference is then not with the language itself, it is with the implementation.

As I was initially trying to point out, as far as the C language is concerned, there is no difference between the two.

Here is the information to which I was referring:

The mode string can also include the letter ``b'' either
as a third character or as a character between the charac-
ters in any of the two-character strings described above.
This is strictly for compatibility with ANSI C3.159-1989
(``ANSI C'') and has no effect; the ``b'' is ignored.

In otherwords, if you have a compliant compiler, it should have no effect.

[edit]
Again, the point is illustrated. The '\r' is automaticly discarded when reading in text mode. In effect, it exists only while on disk while under said OS.

To illustrate the point, open the .txt version of the file in my code with the following two additions:

Code:

	fpt = fopen( "blah.txt", "r" );
	do
	{
		x = fgetc( fpt );
		if( x == '\r' )
		{
			printf("\\r inserted by OS.\n");
			printf("You will never see this.\n");
		}
	}while( x != EOF );
	fclose( fpt );

	fpb = fopen( "blah.txt", "rb" );
	do
	{
		x = fgetc( fpb );
		if( x == '\r' )
			printf("\\r inserted by OS.\n");
	}while( x != EOF );
	fclose( fpb );

[/edit]

Quzah.

>>Maybe he was really tired.
Nope

>>Or perhaps, he was on the phone.
Maybe, I can't remember, but it was a busy day

>>I believe that currently the "b" attributes are just hold overs for compatibility with old compilers
>>as far as the C language is concerned, there is no difference between the two
Not so, read on.

>>http://www.rt.com/man/fopen.3.html
This is a Unix man page, and as such can have a biased opinion on life.


OK, enough of the quotes, let's get down to business. When I wrote my original post, my brain was thinking faster than I could type, and unfortunately I never got to finish my sentence. This is where the confusion comes from. I don't need to go into any details of fwrite/fread as they've already been covered by everyone in this thread (heavy-weight thread it is too, eh?!). The problem, comes from the OP's use of fseek() on the file stream, that is used for fread() and fwrite(). They are quite clearly attempting to open the file, fseek() to a specific struct instance, and then fread() it in; and to do that they must use a binary stream. fseek() requires different parameters depending on the stream mode. To save me waffling on about it, here's the C99 rules for it:

Code:

ISO/IEC 9899:1999 (E)
7.19.9.2 The fseek function

1 #include <stdio.h>
int fseek(FILE *stream, long int offset, int whence);

3 For a binary stream, the new position, measured in characters from the beginning of the
file, is obtained by adding offset to the position specified by whence. The specified
position is the beginning of the file if whence is SEEK_SET, the current value of the file
position indicator if SEEK_CUR, or end-of-file if SEEK_END. A binary stream need not
meaningfully support fseek calls with a whence value of SEEK_END.

4 For a text stream, either offset shall be zero, or offset shall be a value returned by
an earlier successful call to the ftell function on a stream associated with the same file
and whence shall be SEEK_SET.

So, you can see that the OPs use of fseek() is illegal; this is where I was coming from in my original post.

I presume that reason for the difference in behaviour of fseek() is purely because of the problems generated by the OS's need to control how an EOL marker looks in an external file. For example, in text mode, how can you seek to a specific byte offset in the file, when you don't know for sure how many bytes you're traversing in the underlying system? Did the programmer ask for an N-byte offset with expanded EOLs or contracted EOLs, who knows? No-one, so seeking on text mode files is not feasible.

So, in summary, I'll change my original line to:

- fseek() requires the file to be opened in binary mode, when used in the context of the OPs code.

Sorry for not stating the obvious in the first place, I can see I've caused you all to think hard for no reason.

For the reader, here is some code to help your test this out.

Code:

#include <stdio.h>

/*
 * Change this mode parameter to the desired one to see the different effects
 */
#define MODE "r+"
/* #define MODE "r+b" */

struct foo 
{
  int i;
};

int main(void)
{
  struct foo bar[2] = {10, 20};
  FILE *fp;
  
  if ((fp = fopen("test.bin", MODE)) == NULL)
  {
    perror ("test.bin");
    return 0;
  }
  
  /* Write both structs */
  fwrite (bar, sizeof (bar), 1, fp);

  /* Point to second struct */
  fseek(fp, sizeof(bar[0]), SEEK_SET);
  
  /* Read second struct back into first struct in the array */
  fread (bar, sizeof (bar[0]), 1, fp);
  
  fclose(fp);
  
  printf ("This should say 20: %d\n", bar[0].i);
  
  return(0);
}

/*

Output when run in binary mode:
This should say 20: 20

Output when run in text mode (might be different on your compiler):
This should say 20: 5120

*/