LINUX file structure, compared to normal open,read,write __linux

The completion of the process to achieve the data to save, but encountered a large number of problems, originally intended to use SQLite, but due to storage speed and complexity, or with file implementation.

1. Linux open, read, write these are used for writing file descriptors, but for the file operation is still not very clear ...

。。。。。。。。。 Mark it first .....

2. Read the time can always read only one line, Fread, Fwrite, fclose.

3. Write the data only one line, in the file structure, to use at

How the file is used

RT Read-Only opens a text file, only read data "WT" only write open or create a text file, only write data "at" Append open a text file, and write data at the end of the file "RB" read only open a binary file, only allow read data "W" B "Write only open or create a binary file, only write data" AB "Append open a binary file, and write data at the end of the file" rt+ "read and write open a text file, allow reading and writing" wt+ "read and write open or create a text file, allow read and write Read and write "at+" to open a text file, allow read, or append data at the end of the file "rb+" read and write to open a binary file, allowing read and write "wb+" reading and writing to open or create a binary file, allowing read and write "ab+" read-write open a binary file, allow Permission to read or append data at the end of the document

4.FILE of Eof=-1, this look at the following

(1) Bytes read
Under normal circumstances, Getc reads the file stream in unsigned char, expands to an integer, and returns. In other words, GETC takes a byte from the file stream, adds 24 zeros, becomes an integer less than 256, and returns.

int C;
while ((c = fgetc (RFP))!=-1)//-1 is EOF
FPUTC (c, WFP);

The C in the above FPUTC is an integer, but before FPUTC writes it to the file stream, it also removes the high 24 bits of the integer, so fgetc, PUTC with the ability to achieve file replication. So far, it is still possible to define C as char, but we will see that the definition of C as int is for the correct sentence to end the file.


(2) Judge the end of the document.
Most people think that there is an EOF in the file to indicate the end of the file. But this view is actually wrong, and there is no file terminator in the data contained in the file. For getc, if you can't read from a file, you return an integer-1, which is called EOF. Back to EOF there are only two situations, one is that the file has been read; Second, the file read error, anyway, is not read down.


Note that in the case of normal reading, the returned integer is less than 256, or 0x0~0xff. And can't read out the return is 0xFFFFFFFF. However, if you write 0xFFFFFFFF to the file with FPUTC, the high 24 bits are blocked and the write will be 0xFF. Lixforalpha please pay attention to this point


(3) 0xFF will make us confused?

No, provided that C that receives the return value is defined as int by prototype.
If the next read character will be 0xFF, the

int C;
c = fgetc (RFP); c = 0x000000ff;
if (c!=-1)//Of course ranged,-1 is 0xFFFFFFFF
FPUTC (WFP); Oh, Oxff copied successfully.


Character 0xFF, which itself is not EOF.


(4) defines a C char

Assuming that the next read character is 0xFF

char c;
c = fgetc (RFP); The value of the FGETC (RFP) is 0X000000FF and is dropped to bytes.


c = 0xFF
if (c!=-1)//character compared with integer? C is extended with a signed (signed) to


0xFFFFFFFF, Ooh Oh,
The condition is set up, file copy quits early.


while ((C=FGETC (RFP)) in the!=eof of the criteria set up, file copy end! Meaning


Outside suspension.


(5) Defining C as unsigned char;


When you read the end of the file and return EOF--1,


unsigned char c;
c = fgetc (RFP); The value of FGETC (RFP) is EOF, that is, 1, 0xFFFFFFFF, drop


Lattice is byte, c=0xff
if (c!=-1)//C is extended to 0x000000ff, never return equals


0xFFFFFFFF


So this time, although the correct copy of 0xFF, but can not determine the end of the file. In fact, in C


For Uchar,
C!=-1 is always set up, a high-quality compiler, such as GCC will be at compile time to refer to


Out this point.


(6) Why do we need feof?
FILE *FP;
FP points to a very complex data structure, feof is judged by the signs in this structure.


Whether the file is finished.
If the file is read with fgetc and the last character is read out, the EOF flag in the FP


Not open, when
Judging by feof, you will get the conclusion that the document is not yet closed.


FGETC return-1, we still cannot be sure that the file has ended because it might be a read error


Miss! Then we
Need feof and ferror.