Endianness of BHV2?
Posted by bpjackson
|
Endianness of BHV2? August 26, 2023 06:11PM |
Hello again!
I was thinking about writing a MEX'ed BHV2 read function (and also one that could be used to support the files from other tools), but when I looked at the documentation, there was no explicit mention endianness of the format. Judging from the parts of the library I've read through to try to find it, it seems like it might just be set to the machine's native endianness, which might complicate things a little (in practice, hopefully not very often?) in terms of the files' portability, since you have to kind of guess whether the bytes need to be flipped.
I'm using a crude heuristic at the moment: that none of the variables' names are longer than 2^32 - 1 characters (which is probably fine) and therefore the upper four bytes of the length field will be zeros. If those are the first four bytes, it's big-endian, and if not, it's little-endian.
One suggestion would also be to just always put the machinefmt field first, since its variable name is of known length, and it already identifies "ieee-le" in my case (a second indicator that my machine is, as most Windows machines, little-endian); the unfortunate thing about it right now is that unless I establish endianness I can't really find it as quickly. This change, as far as I can tell, is simply transposing lines 38 and 39 of mlbhv2.m, which are:
The other benefit of doing this - since the variable name machinefmt is always going to be 10 characters, is that a little-endian machine will always have 0x0A as the first byte, and a big-endian machine will always have a 0x00 byte, which means I'd only have to peek at the first character to know enough to read the first field and get the machine format.
If I do write a C/C++-based BHV2 function, you're welcome to have it; I've been hearing that faster reads would be welcome from the folks I'm collaborating with, and since you were so quick to help me with the last couple things, it only seems fair to give back
I was thinking about writing a MEX'ed BHV2 read function (and also one that could be used to support the files from other tools), but when I looked at the documentation, there was no explicit mention endianness of the format. Judging from the parts of the library I've read through to try to find it, it seems like it might just be set to the machine's native endianness, which might complicate things a little (in practice, hopefully not very often?) in terms of the files' portability, since you have to kind of guess whether the bytes need to be flipped.
I'm using a crude heuristic at the moment: that none of the variables' names are longer than 2^32 - 1 characters (which is probably fine) and therefore the upper four bytes of the length field will be zeros. If those are the first four bytes, it's big-endian, and if not, it's little-endian.
One suggestion would also be to just always put the machinefmt field first, since its variable name is of known length, and it already identifies "ieee-le" in my case (a second indicator that my machine is, as most Windows machines, little-endian); the unfortunate thing about it right now is that unless I establish endianness I can't really find it as quickly. This change, as far as I can tell, is simply transposing lines 38 and 39 of mlbhv2.m, which are:
write(obj,-1,'IndexPosition'); write(obj,obj.fileinfo,'FileInfo');
The other benefit of doing this - since the variable name machinefmt is always going to be 10 characters, is that a little-endian machine will always have 0x0A as the first byte, and a big-endian machine will always have a 0x00 byte, which means I'd only have to peek at the first character to know enough to read the first field and get the machine format.
If I do write a C/C++-based BHV2 function, you're welcome to have it; I've been hearing that faster reads would be welcome from the folks I'm collaborating with, and since you were so quick to help me with the last couple things, it only seems fair to give back