0

As far as you know, there are two standard to read a text file in C++ (in this case 2 numbers in every line) :

The two standard methods are:

Assume that every line consists of 2 numbers and read token by token:

#include <fstream>
std::ifstream infile("thefile.txt");    
int a, b;
while (infile >> a >> b)
{
    // process pair (a,b)
}

Line-based parsing, using string streams:

#include <sstream>
#include <string>
#include <fstream>
std::ifstream infile("thefile.txt");

std::string line;
while (std::getline(infile, line))
{
    std::istringstream iss(line);
    int a, b;
    if (!(iss >> a >> b)) { break; } // error

    // process pair (a,b)
}

And also I can use the below code to see if the files ends or not :

while (!infile.eof())

My question is :

Question1: how this functions understand that one line is the last line? I mean "how eof() returns false\true?"

As far as I know, they reading a part of memory. what is the difference between the part that belongs to the file and the parts that not?

Question2: Is there anyway to cheat this function?! I mean, Is it possible to add something in the middle of the text file (for example by a Hex editor tools) and make the eof() wrongly returns True in the middle of the text file?

Appreciate your time and consideration.

Krupa Patel
  • 3,309
  • 3
  • 23
  • 28
  • read on this http://stackoverflow.com/questions/12389518/representing-eof-in-c-code – Thusitha Thilina Dayaratne Aug 02 '14 at 05:18
  • It does not understand what is the last line. In fact, it passes the last line. If it tries to read, but there is no more characters to read, then EOF is set to true. – Naetmul Aug 02 '14 at 05:20
  • Are you asking whether a file can contain text plus some hidden binary data which isn't part of the text stream? You might want "alternate data streams" (Windows) or "resource forks" (Mac) – Ben Voigt Aug 02 '14 at 05:21
  • If your question is: "how does `while (!infile.eof())` recognize the end of file", the answer is "poorly". http://stackoverflow.com/a/24483590/179910. As to whether it can make a mistake: depending on the OS and file opening mode, yes. For example, if you open a file as text, a ctrl-z may be treated as the end of the file. – Jerry Coffin Aug 02 '14 at 05:24
  • 2
    You're not reading a part of memory, you're reading from a file. The operating system keeps track of the size of the file, and won't let the program read past the end of it. The C++ runtime library detects this condition and sets the EOF flag on the stream when it occurs. – Barmar Aug 02 '14 at 05:30
  • @Naetmul what do you mean by **No more character to read**? let assume that our text file saved in address 0x1000 to 0x1100 in memory, and another text file followed after this text file. what make difference between this two text file for `eof()` function? –  Aug 02 '14 at 05:41
  • ...be wary of the difference between files and memory. – polarysekt Aug 02 '14 at 05:44
  • @BenVoigt maybe yes. I want to add some data (text or ...) in the end of a text file and when I try to read it they don't recognize as file contents. for example assume my origin text file have 5 lines data. I want to add 2 more line in the end of it, but when I use the above source code, the program just the the first 5 line. –  Aug 02 '14 at 05:45
  • @JerryCoffin can I add something to the text and make program act wrong? I mean make the some lines hide to read! –  Aug 02 '14 at 05:47
  • @Barmar Thank you dear Barmer. is there any way to cheat this runtime library? please take a look at above comments. –  Aug 02 '14 at 05:50
  • No there isn't a way. It's not looking at anything in the file, it's using the file metadata. – Barmar Aug 02 '14 at 05:51
  • What are you trying to accomplish by cheating it? – Barmar Aug 02 '14 at 05:52
  • @Barmar I want to test a device that created to send text files with just x line data from a flash memory to a laptop. I want to test it by sending files with more than x line! (this device is created to prevent moving virus infected text files) –  Aug 02 '14 at 05:57
  • @Barmar what is file metadata? can I change it? do you have any other idea to make the device work wrong? –  Aug 02 '14 at 05:59
  • If you're trying to program computers, shouldn't you know the basics of how computers and operating systems work? – Barmar Aug 02 '14 at 06:02
  • 2
    The OS updates the metadata when you change the file. IF you add a character to a file, it increases the length. If you change permissions on the file, it updates the permission modes. – Barmar Aug 02 '14 at 06:03
  • @Barmar So you mean there is no any any way to send a text file with more that 5 line contents to the laptop via this device? (assume the device use above codes to read text file in flash memory) –  Aug 02 '14 at 06:10
  • I have no idea what you're talking about. Of course you can have files longer than 5 lines. – Barmar Aug 02 '14 at 06:14
  • Dear @Barmar I have a device that connect to my personal computer with a Ethernet cable. this device also has a USB port. when I connect a flash memory to the device, the programs that uploaded on the device search the flash for text files with 5 lines and move them to the computer. I want to know, is there any way to move text files with more than 5 lines to the computer via this device? Is my question clear? Thank you. – TheGoodUser Aug 02 '14 at 06:23
  • Sorry, I don't know anything about your device. If it has a 5-line limit, that's not a programming issue. – Barmar Aug 02 '14 at 06:24
  • @Barmar It has a counter in `while (!infile.eof())` loop. and if the counter value greater than 5, it ignore the file.What about this case? Sorry of being stubborn :( :) – TheGoodUser Aug 02 '14 at 06:32
  • You should never use that construction: http://stackoverflow.com/questions/5431941/while-feof-file-is-always-wrong – Barmar Aug 02 '14 at 06:34
  • If you are making a security device, you really shouldn't be using complex (1000s of SLOC) C++ iostream libraries, you should use OS functions and end-of-file detection logic *under your control*. Maybe not even the OS file functions, if you're worried they might have unexpected behavior like reporting end-of-file too early. – Ben Voigt Aug 02 '14 at 15:37

1 Answers1

2

Question1: how this functions understand that one line is the last line? I mean "how eof() returns false\true?"

It doesn't. The functions know when you've tried to read past the very last character in the file. They don't necessarily know whether a line is the last line. "Files" aren't the only things that you can read with streams. Keyboard input, a special purpose device, internet sockets: All can be read with the right kind of I/O stream. When reading from standard input, the stream has no knowing of if the very next thing I type is control-Z.

With regard to files on a computer disk, most modern operating systems store metadata regarding the file separate from the file. These metadata include the length of the file (and oftentimes when the file was last modified and when it was last read). On these systems, the stream buffer than underlies the I/O stream knows the current read location within the file and knows how long the file is. The stream buffer signals EOF when the read location reaches the length of the file.

That's not universal, however. There are some not-so-common operating systems that don't use this concept of metadata stored elsewhere. End of file on a disk file is just as surprising on these systems as is end of file from user input on a keyboard.

As far as I know, they reading a part of memory. what is the difference between the part that belongs to the file and the parts that not?

Learn the difference between memory and disk files. There's a huge difference between the two. Unless you're working with an embedded computer, memory is much more limited than is disk space.

Question2: Is there anyway to cheat this function?! I mean, Is it possible to add something in the middle of the text file (for example by a Hex editor tools) and make the eof() wrongly returns True in the middle of the text file?

That depends very much on how the operating system implements files. On most modern operating systems, the answer is not just "no" but "No!". The concept of using some special signature that indicates end of file in a disk file is one of many computer science concepts that for the most part have been dumped into the pile of "that wasn't very smart" ideas. You asked your question on the internet. That most likely means you are using a Windows machine, a Linux machine, or a Mac. All of them store the length of a file as metadata separate from the contents of a file.

However, there is a need for the ability to clear the end of file indicator. One program might be writing to a file while at the same time another is reading from it. The reader might hit EOF while the writer is still active. The reader needs to clear the EOF indicator to continue reading what the writer has written. The C++ I/O streams provide the ability to do just that. Every I/O stream has a clear function. Whether it works, that's a different story. The clear will work temporarily, but the very next read might well reset the EOF bit. For example, when I type control-Z on my keyboard, that means I am done interacting with the program, period, My next action might well be to go out for lunch.

David Hammen
  • 32,454
  • 9
  • 60
  • 108
  • The OS may have metadata storing the length, but there is no guarantee that the OS idea of "end of file" is the only criterion the C++ runtime library uses. Some implementations do recognize an "end of text" sort of marker, when the file is opened with text-mode translation active. And some of these implementations are encountered on modern OSes. – Ben Voigt Aug 02 '14 at 15:34
  • @BenVoigt - I hope I didn't give the impression that the OS idea of EOF is the only criterion that the C++ library uses to determine where a stream buffer signals EOF to the I/O stream. For one thing, that is very implementation-dependent. For another, a custom I/O stream and stream buffer that inherits from the standard I/O stream and stream buffer to implement a partitioned file (multiple logical files within a physical file) wouldn't work. But it does work precisely because the standard doesn't say how EOF is stored or is signaled. – David Hammen Aug 02 '14 at 16:04
  • Well, you said *On most modern operating systems, the answer is not just "no" but "No!".*, as if the OS would prevent the runtime library from implementing other logic. In reality, if he wants to take advantage of the OS reliable end-of-file information, he needs to use the OS function for it. – Ben Voigt Aug 02 '14 at 16:08
  • The comments on the question also cast doubt on "most likely means you are using a Windows machine, a Linux machine, or a Mac", since he mentions an embedded device. – Ben Voigt Aug 02 '14 at 16:11