EOF ASCII/HEX code in text files

Question

As far as know in the end of all files, specially text files, there is a Hex code for EOF or NULL character. And when we want to write a program and read the contents of a text file, we send the read function until we receive that EOF hexcode.

My question : I downloaded some tools to see a hex view of a text file. but I can't see any hex code for EOF(End Of File/NULL) or EOT(End Of Text)

---

ASCII/Hex code tables :

This is output of Hex viewer tools:

---

Note : My input file is a text file that its content is "Where is hex code of "EOF"?"

Solution 1

Traditionally, in some contexts there is a End-of-file 'character' - MS-DOS / CMD.EXE uses CTRL+Z - Linux uses CTRL+D

CTRL-Z is code 26, CTRL-D is code 4 in the ASCII table.

These are still in use in situations when you use stdin (in the meaning as applied in "C" programming and general console/tty IO).

e.g.

C:\> copy con myFile.txt
This is text to go into the file.Enter
CTRL+Z
C:\> type myFile.txt
This is text to go into the file.
C:\> 

The very same sequence works in Linux'en with the difference that you start with

$ cat >myFile

and end with CTRL+D, then cat myFile.txt instead of type.

... If you're programming though, you will hardly see any effects of these characters.
I am at this writing not aware of any function call that would stop at these characters.
Read the documentation for your software / library - if there is no statement about the effect of these, then you're not likely to see anything strange happen.

Line endings - CR and LF combinations, code 13 and 10 - is a bit different though, it can get quite messy if you transfer TEXT files from one system to another. unix2dos and dos2unix are shell commands available on Linux'en - for this purpose.

Sample bash session:

$ echo -e "First line\n\x04Second line."
First line
Second line.

$ echo -e "First line\n\x04Second line." | od -t x1z
0000000 46 69 72 73 74 20 6c 69 6e 65 0a 04 53 65 63 6f  >First line..Seco<
0000020 6e 64 20 6c 69 6e 65 2e 0a                       >nd line..<
0000031

$ echo -e "First line\n\x04Second line." | grep line
First line
Second line.

$ cat >myFile.txt
Check this out

$ cat myFile.txt
Check this out

$ 

Solution 2

No, EOF is not a special character, lol :)

Take a look: http://www.cplusplus.com/reference/cstdio/EOF/

It is basically a macro:

End-of-File
It is a macro definition of type int that expands into a negative integral constant expression (generally, -1).

It is used as the value returned by several functions in header <cstdio> to indicate that the End-of-File has been reached or to signal some other failure conditions.

It is also used as the value to represent an invalid character. 

In C++, this macro corresponds to the value of char_traits<char>::eof().

That means, the API try to read a line of file, get -1 and returns EOF. In contrast to EOF, the CR/LF are such special characters, you can see them in the HEX Editor if you have some line breaks:

'\n' or '0x0A' (10 in decimal) -> This character is called "Line Feed" (LF).
'\r' or '0x0D' (13 in decimal) -> This one is called "Carriage return" (CR).

---

Apart of the files, there is a '\0' character on the end of the array of character in memory, it marks the end of the string. Without it, the computer has no way to know how long that group of characters goes. When you print/copy/whatever a string, it just keeps printing/copying chars until it finds that null char... that's when it knows to stop.

Maybe you mean this one NULL?

Comments

[Ebrahim Ghasemi]

I wrote a program that searched a text file for character "A" . And if there is no "A" in the text, move the file to a special directory. I want to know is there any way to cheat my program? for example "adding a NULL/EOF/EOT hex code in the middle of my input text"? I want to know is there any any way to cheat the program by only changing the text file? Assume that they can't install or edit anything in the host (that my program installed in it.) thank you

[Ebrahim Ghasemi]

would you please take a look at my comment below the previous answer? (below duDE answer). Thanks

[Hannu]

If you use a read() function in binary mode, or even linefeed translating mode - and nothing else is specified in the documentation for that function - then my conclusion is; no nothing can fool it. But to be more certain of the ACTUAL case for yourself, using your tools, you need to VERIFY this by testing. - the actual situatio depends entirely on how the tool-provider and/or library code is written - and there I can ONLY guess, as anybody else.

[Leo Chapiro]

Yes, there is a way - your program can be diasassembled: en.wikibooks.org/wiki/X86_Disassembly/Objects_and_Classes