file operations

hello

is there a way i can find out a files location in memory?

if i use

Code:

---

FILE *fp;       

        if((fp=fopen(fname,"w")) == NULL){
                return 0; //return failure
        }

---

if i did "&fp", will that give me the location of the first byte of the file in memory?

and suppose the file is 16 bytes long..can i cycle through each byte one-by-one and read/modify it?


-thanks

no and no
You can get the file content byte by byte by using fgetc().

FILE is a struct (user-defined type) FILE *fp is a pointer to that struct.

What is in the FILE struct is somewhat different for each compiler, but generally has some basic stuff - here is one:

Code:

---

/* Definition of the control structure for streams
*/
typedef struct  {
        short          level;          /* fill/empty level of buffer */
        unsigned        flags;      /* File status flags    */
        char            fd;              /* File descriptor      */
        unsigned char  hold;    /* Ungetc char if no buffer */
        short          bsize;          /* Buffer size          */
        unsigned char  *buffer;  /* Data transfer buffer */
        unsigned char  *curp;    /* Current active pointer */
        unsigned        istemp;    /* Temporary file indicator */
        short          token;          /* Used for validity checking */
}      FILE;                            /* This is the FILE object */

---

So, you can access the buffer like this:

Code:

---

char *tmp;
tmp = calloc(1,BUFSIZ+1);
strncpy(tmp,r->buffer,fp->bsize);
printf("my file buffer has this is in it:%s\n", tmp);
free(tmp);

---

The file is NOT in memory somewhere, unles you have read it into a string array or whatever.

does "buffer size" give me the size of the file?

No it gives you the size of the current read buffer.

You should NOT use the internal structures, always use the accessor/mutator functions. If you want the size of a file, use stat (#include <sys/stat.h>).

err...what are those?

i did:

Code:

---

        while(!feof(fp)){
                tmp = getc(fp);
                ::fsize+=1;       
        }

---

to get the file size, it came out accurate...i and i timed it with GetTickCount()...0.0000ms...i guess thats good enough.

another question too..
i also did:

Code:

---

        char tmp = (char) malloc(1 * sizeof(char));
                ...
        free((void *)tmp);

---

is that good/clean?

VC++ doesn't like it.

how do de-allocate memory?

Code:

---

while(!feof(fp))
{
        tmp = getc(fp);
        ::fsize+=1;
}

---

HAHA try that with a 1 MB file :D

Better way:

Code:

---

fseek(fp, 0, SEEK_SET);
size = ftell(fp);

---

Or use parksies way...

Code:

---

char tmp = (char) malloc(1 * sizeof(char));
...
free((void *)tmp);

---

A) The main problem is that you need to cast the return of malloc to a pointer:

Code:

---

char* tmp = (char*) malloc(1 * sizeof(char));
...
free((void *)tmp);

---

B) This is no good use for dynamic memory. You use dynamic memory when a) you don't know the amount you'll need or b) when you want a really big block of memory - at least several hundred bytes. Everything else can be allocated on the stack.

C) You seem to use C++ (not pure C), so you should use new and delete instead:

Code:

---

char* tmp = new char;
...
delete tmp;

---

Isn't that cleaner?

File size -

FWIW - ftell does not "ftell" the truth all the time.
For: FILE fp=fopen("myfile","r") ftell() doesn't count EVERY character.

Why?

It converts CrLf (two characters) into \n a single character.
Depending on the OS there may other similar problems with file length.

In ANSI C the standard ways to get file length are:

with stat()

Code:

---

#include <sys/stat.h>
long FileLen(char *filename){
stat *buf;

 if(!stat(filename,buf){
    return (long) buf->st_size;
 else
    return 0L;
}

---

or with:

[code]
long FileLen(char* filespec){
FILE *fp;
long f;

fp=fopen(filespec,"rb");
fseek(fp,0,SEEK_END);
f=ftell(fp);
fclose(fp);
return f;
}

stat() is the preferred way because it doesn't involve file i/o.
Both work reliably. MS doesn't document either one very well - ie., you can't put this all together without some legwork. IMO.