urgent: make off_t 32 bits...

Perhaps you could describe what kind of file-pointer manipulations you need to do, and show the code that is difficult to work with.

Also, what function are you using to retrieve the 64 bit file position?

hi phoffric,

on the 32 bit platform, sizeof (off_t) is 8 bytes..
to make things easier for me, i am trying to make it work for small file (48 bytes) and then, i would try for large files..

i am writing 4 bytes of unsigned int to disk. there are times when i read the first 4 bytes (which is unsigned int) and then, i need to write another value on that position or on the next 4 bytes...


if off_t is 8 bytes, it is placing its pointer at the start of the second unsigned int value,but on the start of the third...

if off_t is 8 bytes, it is not placing its pointer at the start of the second unsigned int value,but on the start of the third...

for example, value in file is
 2 4
[4 bytes][4 bytes]

It won't hurt to store a 32-bit unsigned long quantity and cast it to 64 bits, as long as the file is under 4 GiB.  Or even signed long, and under 2 GiB.  I'm not sure that you need to though; I'd like to see what you're trying to do too.

What does the contents of the file have to do with the size of off_t?  Are you writing the offsets to the file for some reason?

Hi zizi21,

Are you doing anything different because you find that off_t is 64 bits? The offset, according to the lseek link, is just a "count of characters" so a 64 bit off_t should allow you to put in larger offsets and go beyond the 4GB limit. But the fact that it is 64 bits shouldn't make a difference, at least not for your small files.

I checked on my cygwin platform for the sizeof(off_t) and the sizeof(size_t). They are 8 and 4, respectively. So, maybe I can help. If you would like to post a full program (cut to a few lines in a main that builds) and runs, but produces the wrong data in the wrong offsets, I'll be happy to try to see if I can reproduce the problem on cygwin.

See you tomorrow if you still need help. Good luck!

sorry for the late reply..i had to rush for a class which i thought i could skip..

while(!feof(fp))
{

fread(&y,sizeof(unsigned int),1,fp);

}

i think, i have confused the 64 bit stuff with normal coding..so i have removed everything that i have added and just pretend it is for 32 bit..i am going to work on it now...i really appreciate of all your help into looking into this..

>>  i have added and just pretend it is for 32 bit
Good plan :)

I'll wait to hear from you.

-->phoffric:
See you tomorrow if you still need help. Good luck!

thanks..

-->evilrix
'll wait to hear from you.

thanks...

thank you all so much and God bless you,

zizi21, you are most welcome. It's wonderful to assist someone who appreciates us. That means so much more than the points :)

>>>> manipulating the positions with the filepointer...having it behave like 64 bits is difficult...could i force it to be 32 bits....

If you want to store file positions somewhere it firstly is a logical problem and not a technical one. Assume you know for sure that your files were all smaller than 4 GB. Then you *always* can store the position as 32bit integer even if ýou retrieved it as 64-bit integer. Simply cast it to UINT32 (what is a typedef of unsigned int on a 32bit platform) and store the byte position that way. If files got bigger you either could store 64-bit (or 48-bit) integers what would be enough for ever ... or if you were stuck on 32 bit for storing you could consider whether your file positions could be counted in records rather than in bytes. If for example you have 256 byte records and your positions always would/could point to the begin of such a record, you easily could store 'record numbers' for files of size 1000 GB with that approach.

The issue is that off_t can be either 32 bit or 64 bit, depending upon how it's compiled (if LFS is enabled). If you go casting from off_t to unsigned int without knowing if the file you are opening is > 2GB you, potentially, introduce a very hard to track down defect (trust me, I know... I spent a few days tracking down this exact type of bug a couple of months ago when another programmer made an assumption, much as this, on code built to handle large files).

Whilst I agree that your answer is, technically, correct... I'd very much recommend not doing this unless there is a compelling reason to do so.

thank you very much and God bless you all. .i really appreciate it.

evilrix,

"zizi21, you are most welcome. It's wonderful to assist someone who appreciates us. That means so much more than the points :)"

thank you very much for your kind words...