In documentation, see:
- Field
- Structure packing/field alignment
problem with binary read/write
Re: problem with binary read/write
No problem, as you're dead right. As I already stated, I coded it in a hurry =DMrSwiss wrote:Sorry to butt in on this, but using Integer (in UDT), for file access (any method),
is actually *asking for troubles*, because SizeOf(Integer) varies, with the used
version of FBC (32/64 bit's), making the file unusable, when accessing with a
.exe compiled with the *other* FBC!
Effectively, padding in a file doesn't make any sense, only in memory (memory aligned read/writes are faster; also, some architectures don't even support reading from unaligned addresses), but you DO have to take it into account when reading/writing to a file. Another thing you need to take into account is the order of the elements of a structure:sero wrote:@paul doe - I didn't know about field alignment until just now. I don't understand the purpose of this. The manual talks about padding which doesn't make any sense to have padding in a binary file. I changed the field = to 1, then 2, then 4 and the file size was not impacted at all. So what exactly does this do?
Code: Select all
'' Size of the type is 16 bytes, right?
type myType1
as ubyte a, b, e, f
as double c
as long d
end type
? sizeOf( myType1 ) '' Wrong!
type myType2
as long c
as ubyte a, b, e, f
as double d
end type
? sizeOf( myType2 ) ' ' More like it
sleep()
Re: problem with binary read/write
fxm, is this normal behavior? I mean, writing to an arbitrary position into a binary file opened with 'access write' wouldn't just write the bytes you specify, where you specify, instead of zeroing everything up to that point? Or I am missing something? I've had to open it as 'access read write' to pull this off without erasing all the data before the position I specified. I don't recall having this problem before...
Re: problem with binary read/write
I see, it's a file system quirk, not a FB bug. Thank goodness ;)
Re: problem with binary read/write
Sorry, mate. Didn't see this post until now =Djj2007 wrote:We have treated these issues in the Set EOF thread just a few weeks ago.
Re: problem with binary read/write
To my knowledge, there has never been a change in the compiler on this behavior.paul doe wrote:I don't recall having this problem before...
Re: problem with binary read/write
That's ok, perhaps it was on another language and I don't remember which. Thanks.fxm wrote:To my knowledge, there has never been a change in the compiler on this behavior.