1

Suppose i open a text file in write mode using c language. Now I add some text data to it.

1.Internally how is data stored in file ? Is each character stored as 8 bit ascii code ?

We Never add EOF at the end of writing to file and we use fclose() to close the file .

2.How is then EOF added to file ? How is it stored in file ?

When we read character by character of that file using getchar() , We are able to detect EOF. Now EOF if is ctrl+z , these are 2 characters ^z are saved at end of file. So getchar() will get ^ and then z . so,

3.How does getchar() detects EOF ?

Number945
  • 4,631
  • 8
  • 45
  • 83
  • Yes, characters are individually stored as 8-bit BYTES. If you write out ASCII, then you get ASCII. If you write out a byte `0x02` then you get a byte `0x02`. EOF is the return that a file reading function provides when it knows it's at the end of a file. It's not actually anything inside the file. The functions know they're at the end because the file system provides information about the length of the file, and the file I/O functions keep track of where they are in the file. – lurker May 20 '14 at 16:37

2 Answers2

1
  1. Typically C will be using Latin-1 or some other single byte encoding, but it should be possible to use UTF-8 locale setting. Note that most C character/string handling routines will not properly handle UTF-8 or any other multibyte encoding -- you have to use special libraries.

    It depends on the Operating System used, but most will simply store a continuous stream of characters, with a Line-End (CR-LF in Windows, \n in Unixy systems) character to mark the end of the line (YOU have to explicitly put it there).

  2. Some Operating Systems, such as MS-DOS, may explicitly write an EOF character to the end of the file, but most don't. They simply run off the end of the file and report a status of EOF.

  3. See 2.

Phil Perry
  • 2,126
  • 14
  • 18
1

EOF is not a character that gets stored in a file, it is a special return code that you get when you read a file. The file I/O system knows how many characters there are in a file, because it stores the exact length of the file. When your program tries to read a character after the last available character, the file I/O system returns a special value EOF, which is outside the range of char (it is for that reason that character reading routines such as getchar() return an int instead of a char).

The Ctrl+Z sequence is not an EOF character either. It is a special sequence of keys that tells the shell to close the console input stream associated with the program. Once the stream is closed, the next read returns EOF to your program. It is important to understand, however, that Ctrl+Z is merely a keyboard sequence that is interpreted by the command line processor - in the same way that Ctrl+C is a sequence that tells the command line processor to terminate the program.

Finally, ^Z is not two characters that get stored in a file, it's a screen representation of the Ctrl+Z sequence produced by the command line processor to confirm visually that the keyboard sequence has been accepted.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • Microsoft DOS _did_ store an explicit EOF code (x1B, IIRC) in a file, at least in some languages and some editors. – Phil Perry May 20 '14 at 16:46
  • @BreakingBenjamin It's not "reading" it in the same sense that it reads other character codes. Returning `EOF` to your program requires special handling. The I/O library looks at the file or the console stream, and checks if the current reading pointer is at the end. If it is, `EOF` is returned; if it isn't, the next character from the file / stream is returned to your program. – Sergey Kalinichenko May 20 '14 at 16:53
  • If that be the case what is use of "explicit EOF code " in DOS – Number945 May 20 '14 at 16:54
  • DOS was a _very_ primitive system, that found it easier to implement an explicit EOF character than to figure out you've run off the end of the file. Whether or not there is an explicit EOF character, the language libraries should return an EOF at the end of a file -- it's not something you have to worry about. – Phil Perry May 20 '14 at 16:56
  • @BreakingBenjamin Explicit EOF in MS DOS has been obsolete for a good number of years, if not decades. [Here is another Q&A you may want to read](http://stackoverflow.com/q/3061135/335858). – Sergey Kalinichenko May 20 '14 at 16:59