fclose() and EOF

This is a discussion on fclose() and EOF within the C Programming forums, part of the General Programming Boards category; Hi, In one book about C programming in Chapter Disk Files I found this explanation: " The function call fclose() ...

  1. #1
    Registered User Micko's Avatar
    Join Date
    Nov 2003
    Posts
    712

    fclose() and EOF

    Hi,
    In one book about C programming in Chapter Disk Files I found this explanation:
    "
    The function call fclose() represents signal to OS (operating system) to "break" connection between program and the file and to release all resources that was needed to maintain this connection. After the file has been closed
    OS automatically adds at the end of the file a special marker called EOF (end of file). EOF has special value that is OS dependent and that value cannot be value that might appear among internal data in the file.
    "
    I translated this as best as I can but I'm sure you'll understand.
    I know that this EOF has nothing to do with EOF defined in stdio.h as (-1).
    I have Win XP and wrote simple program to do some tests.
    Code:
    #include <stdio.h>
    int main()
    {
    	int x=1,i;
    	FILE *fp;
    	fp=fopen("Test.bin","wb");
    	for(i=0;i<1024;i++)
    		fwrite(&x,sizeof(int),1,fp);
    	fclose(fp);
    	return 0;
    }
    I located file Test.bin and in it's properties I found this:

    size: 4,00 KB (4096 bytes)
    size on disk 4,00 KB (4096 bytes)

    I know that size of a cluster is 4,00 KB on my disk so my question is:
    Is this sufficient to conclude that no special values are added in the file?
    If it is (and I suppose it is) how files are stored and maintained by Windows(I mean that special EOF is not part of file)?
    If file is bigger then 4 KB it occupies more than one cluster what structure Windows make to keep track of files?

    I know these last two questions are not for C board but I hope you'll have an understanding and answer.
    Thanks a lot!

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,485
    > OS automatically adds at the end of the file a special marker called EOF (end of file).
    Your book assumes your OS is archaic DOS.
    For some types of DOS text files, this was true.
    But nowadays, every OS stores the length of the file in the directory information. It does not rely on some magic marker in the file to tell it where EOF is
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,163
    *scratches head* If the EOF value was actually stored at the end of the file data, how would you store whatever value EOF is in the file if the OS would interpret it as the end of the file?
    If you understand what you're doing, you're not learning anything.

  4. #4
    Registered User
    Join Date
    Mar 2004
    Posts
    536
    Quote Originally Posted by itsme86
    *scratches head* If the EOF value was actually stored at the end of the file data, how would you store whatever value EOF is in the file if the OS would interpret it as the end of the file?

    You wouldn't. This was used for text files (ascii characters). If you opened a text file and used standard formatted i/o functions (getchar()), for example) there were two ways that you could get an EOF from the function:

    1. The character that was read was 0x1a (control-z)

    or

    2. The file had a length that was exactly an integer multiple of the disk block size and you had already read the last character.

    So, text files could not contain 0x1a as a character in the file.


    In those days, directory information did not contain the exact byte count of the file contents. Nowadays it does.

    Interestingly enough, for Borland bcc32 and Microsoft Visual C++ (version 6.0), files opened as "r" still quit if a 0x1a character is found. Files opened as "rb" do not. For Gnu gcc, 0x1a is not recognized as EOF regardless of how the file is opened.


    Dave

    Try the following, with the attachment I have enclosed:

    Code:
    #include <stdio.h>
    int main()
    {
      int inchar;
      FILE *infile;
      char *inname = "x.txt";
    
      if ((infile = fopen(inname, "rb")) == NULL) {
        printf("Can't open input file %s with \"rb\".\n", inname);
        return 1;
      }
    
      printf("\n\n");
      printf("Here's the result when %s was opened with \"rb\":\n", inname);
      while ((inchar = fgetc(infile)) != EOF) {
        putchar(inchar);
      }
      printf("\n\n");
      fclose(infile);
    
      if ((infile = fopen(inname, "r")) == NULL) {
        printf("Can't open input file %s\n", inname);
        return 1;
      }
      printf("Here's the result when %s was opened with \"r\":\n", inname);
      while ((inchar = fgetc(infile)) != EOF) {
        putchar(inchar);
      }
      printf("\n\n");
      fclose(infile);
    
    
      return 0;
    }

    p.s. enter the following in a command line window:

    type x.txt

    Open x.txt with your favorite text editor.

    Dave
    Attached Files Attached Files
    • File Type: txt x.txt (68 Bytes, 113 views)
    Last edited by Dave Evans; 09-16-2004 at 01:26 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. A development process
    By Noir in forum C Programming
    Replies: 37
    Last Post: 07-10-2011, 10:39 PM
  2. help with text input
    By Alphawaves in forum C Programming
    Replies: 8
    Last Post: 04-08-2007, 04:54 PM
  3. Game Pointer Trouble?
    By Drahcir in forum C Programming
    Replies: 8
    Last Post: 02-04-2006, 01:53 AM
  4. Dividing and EOF
    By Tride in forum C Programming
    Replies: 7
    Last Post: 09-27-2003, 05:26 PM
  5. filei/o
    By james in forum C Programming
    Replies: 12
    Last Post: 10-04-2001, 05:49 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21