Home c EOF behavior in c

EOF behavior in c

Author

Date

Category

I needed to write a function for measuring the value of the file in bytes. That’s what happened:

# include & lt; stdio.h & gt;
#Include & lt; stdint.h & gt;
Uint64_t File_Size (char * file_path) {
  File * File = Fopen (File_path, "Rb");
  UINT64_T SIZE = 0;
  FOR (FGETC (File)! = EOF; Size ++);
  FClose (File);
  RETURN SIZE;
}
INT MAIN () {
  PrintF ("% LLU \ N", File_Size ("File"));
  Return 0;
}

everything works correctly. Then I was interested in EF . After all, it is just a constant equal to -1 . What if the file contains byte -1 (i.e. FF )?

I wrote a program that creates a file of three bytes, each of which – FF .

FPUTC (-1, File); FPUTC (-1, File); FPUTC (-1, File);

doubled hexdump, which the file really contains 3 bytes (FF FF FF ).

further checked the file size using the function, which I wrote at the very beginning. Returned the function correct size – 3 bytes.

I changed the cycle in the function with

for (FGETC (File)! = EOF; Size ++);

on

for (char c = fgetc (file); c! = eof; c = fgeetc (file), size ++);

checked again – the function began to return the size of the file 0, because the first byte is EOF , that is, the end of the file. Objectively, the function should work just as worked. What’s wrong? How it works? How can the EOF file constant be equal to one of the byte in the file? Who thought it up? Maybe I missed something? I checked everything 10 times. Magic.


Answer 1, Authority 100%

FGETC function returns int, t. & nbsp; e. EOF is not 0xff, but 0xFFFFFFF (well, or 0xFFFF on 16-bit platforms). Obviously, such a value in the byte does not climb, and it can be rumped in and can be contained.

There is a nuance that it seems to be the equality of the size of Char and Int’a. But personally, I did not hear about such platforms, so I can not say that there is on this topic.


Answer 2, Authority 50%

According to Standard:

  • Sizeof (Char) & LT; SizeOF (int)
  • fgetc Returns the int type, but the value can be either in the type char type, if the next byte managed or the constant Eof , if not. The constant value does not fall into the char range, if not confused, equal to -1.

So your example

for (char c = fgeetc (file); c! = eof; c = fgeetc (file), size ++)

incorrect, because Comparison of the CHAR 0xFF value with INT -1 (EOF) returns the truth (according to the rules for expanding the iconic types). On the platform with adamored char, you will get an infinite cycle.

In the example of

fgetc (file)! = EOF

FGETC (File) Returns 0x00FF , i.e. Signal +255, which is not equal to -1

UPD ON Comment from QWERTIY

In response by the link there is a reference to the standard, which says that:

  1. Sizeof (char) == 1
  2. Short Minimum range -32768 … 32767.
  3. int :

    • Minimum range -32768 … 32767
    • if possible, processed by the processor for one command

The case of Sizeof (Char) == Sizeof (short) is possible only on platforms, where byte 16 bits. Such exotic is extremely rare.

Sizeof (short) == SizeOF (int) is possible only if the processor has commands only for 16-bit numbers.

and Sizeof (CHAR) == SizeOF (int) Only on the architecture, where at the same time byte 16 bits and there are no 32-bit commands. The general purpose processors of this type are not found more than 30 years, and the microcontrollers are extremely rare.

So yes, theoretically, Sizeof (char) may be equal to Sizeof (int) , but it is too unlikely.

In practice, there is a situation with Sizeof (Char) & LT; SizeOF (short) & lt; = SizeOF (int)


Answer 3

Not an answer, but the option of searching for the end of the file.

Here is the minimum example of the size of the file in C. Cycles are not needed, for this it has long come up with FSEEK, and the eof is not needed at all, there is a seek_end that is everywhere different from the library to the library.

# include & lt; stdio.h & gt;
.....
File * F;
F = Fopen ("Data", "R");
FSEEK (F, 0L, SEEK_END);
Long File_Size = Ftell (F);

Programmers, Start Your Engines!

Why spend time searching for the correct question and then entering your answer when you can find it in a second? That's what CompuTicket is all about! Here you'll find thousands of questions and answers from hundreds of computer languages.

Recent questions