OSDev.org

I looked around for some stuff about FAT12. If it's here I probably didn't use the right search terms.
I was looking around for a strange bug in my FAT12 code the other day and finally found out the problem and solved it, but I have a feeling that it is now dependent on the "endian-ness" of the cpu.
The code regards retrieving entries from the FAT (which are 12 bits each). I originally used a (short *) to retrieve the values, but realized that when the address that it points to is odd is doesn't work because of address alignment with pointers. I changed over to using an (unsigned char*) and using two calls for it, but I am pretty sure that is endian dependent. Is there an easier way to do this and still be portable?

uglyoldbob wrote:I looked around for some stuff about FAT12. If it's here I probably didn't use the right search terms.

http://wiki.osdev.org/FAT#FAT_12_2

uglyoldbob wrote: I originally used a (short *) to retrieve the values, but realized that when the address that it points to is odd is doesn't work because of address alignment with pointers.

The official Microsoft specs has something about this. Basically all you need to do is use a different part of the 16 bits that you get from the (short*) depending on weather the address is odd or even. There is no need to fiddle with grabbing bytes separately.

Stevo14 wrote:

uglyoldbob wrote:I looked around for some stuff about FAT12. If it's here I probably didn't use the right search terms.

http://wiki.osdev.org/FAT#FAT_12_2

uglyoldbob wrote: I originally used a (short *) to retrieve the values, but realized that when the address that it points to is odd is doesn't work because of address alignment with pointers.

The official Microsoft specs has something about this. Basically all you need to do is use a different part of the 16 bits that you get from the (short*) depending on weather the address is odd or even. There is no need to fiddle with grabbing bytes separately.

If you use the bytes separately, it's portable. If you use it as a short *, it's going to be endian-dependant. Your feeling was backward, reading any value longer than a byte is endian-dependant so the short * is the wrong approach.