# fstream: writing byte offsets

This topic is 4750 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm still working with my filesystem attempting to get everything flowing properly. I'm having a problem writing offets between the structures; here's the code:
p->pHandle->write(0, sizeof(byte_t)*ARCHIVE_FILE_OFFSET );

byte_t is a single character and the offset constant is 8 (I'm attempting to write an 8 byte offset between the file header and archived information inside. The header itself comes out to be 20 bytes; and that's all that's written to the file. It should be 28 bytes (with nothing else). Here's the creation code:
	SysWarn(__FUNCTION__,"Size of header: %d %d",sizeof(p->pHeader),sizeof(byte_t)*ARCHIVE_FILE_OFFSET);

p->pHandle->seekp(0,std::ios_base::beg); // go to the front of the file
p->pHandle->write(0, sizeof(byte_t)*ARCHIVE_FILE_OFFSET );



##### Share on other sites
Perhaps the write function, seeing that the address of the data you want written is 0, chooses to do nothing instead of crashing.

##### Share on other sites
Quote:
 Original post by JohnBoltonPerhaps the write function, seeing that the address of the data you want written is 0, chooses to do nothing instead of crashing.

Bingo, JohnBolton is 100% correct. BKT, this line:
p->pHandle->write(0, sizeof(byte_t)*ARCHIVE_FILE_OFFSET );

Writes 'nothing' to the file. What you need to do is something like this:
char buffer[16];memset(buffer,0,16);snprintf(buffer,16,"%i",sizeof(byte_t)*ARCHIVE_FILE_OFFSET);p->pHandle->write(buffer, sizeof(byte_t)*ARCHIVE_FILE_OFFSET );

The concept is to convert the int that is the file header offset into a string first, then write it out. You may have to recast a few things, but that should do the trick. It is definitly legal, you are writing out 'nothing' to a file, so that's why it does not crash. If you switched to release mode, I could not be so sure of the results.

- Drew

##### Share on other sites
It looks to me like you want to skip 8 bytes ahead in the file, i.e. write that much data but without caring what the data *is*. Unfortunately, you're going to have to specify something to put in that space...

// Stack-allocate some space. Don't bother to initialize it, we don't care about// the contentschar dummy[ARCHIVE_FILE_OFFSET];// Now that we know that address 'dummy' points to at least 8 bytes belonging to// our process, we can use that as a data source:p->pHandle->write(dummy, sizeof(byte_t)*ARCHIVE_FILE_OFFSET );

##### Share on other sites
Thanks guys; I'll check it right now.

EDIT: Yep that was it; thanks guys! One more question though, should I be putting an offset between the file data itself? As of right this is how my archive format looks:

[ Archive Header (20 bytes) ][ Padding Offset (8 bytes)  ][ First File in Archive     ]             ...[ Last File in Archive      ][ Padding Offset (8 bytes)  ][ File Table (one per file) ][ End of File               ]

##### Share on other sites
I would say 'no' on that one. Take a look at this little tutorial on Ryan Clark's Wiki about what he choose to do for a custom file format. I found it really useful and are considering something like it for my project.

- Drew

##### Share on other sites
The only use I can think of for padding is to later insert optional extra data without breaking binary compatability. However, this could be better done by getting it's own section, and if it's "manditory" you'll probably want to intentionally break binary compatability anyways (to prevent older clients from reading, even if by only incrementing the "file type version" in the header)

• 12
• 10
• 11
• 18
• 13