Kevin wrote:
Why would a filesystem driver be platform specific? This doesn't make any sense at all.
Of course it's not the file system driver that's platform specific but rather how the platform deals with the on-device
structs.
Kevin wrote:
Also, can you please explain how using a char array instead of a proper struct fixes endianess issues? I could see how a char array
instead of an int can be used to do this (in a rather tedious way compared to the usual conversion functions), but that's not
related to structs at all.
Here's an example taken from
FATfs a generic cross platform FAT/exFAT file system driver used mainly for embedded devices.
Code:
/* FatFs refers the members in the FAT structures as byte array instead of
/ structure members because the structure is not binary compatible between
/ different platforms */
#define BS_JmpBoot 0 /* x86 jump instruction (3-byte) */
#define BS_OEMName 3 /* OEM name (8-byte) */
#define BPB_BytsPerSec 11 /* Sector size [byte] (WORD) */
#define BPB_SecPerClus 13 /* Cluster size [sector] (BYTE) */
#define BPB_RsvdSecCnt 14 /* Size of reserved area [sector] (WORD) */
#define BPB_NumFATs 16 /* Number of FATs (BYTE) */
and here is one of several functions which access the
byte arrays in an endian neutral way.
Code:
#if _FS_EXFAT
static
QWORD ld_qword (const BYTE* ptr) /* Load an 8-byte little-endian word */
{
QWORD rv;
rv = ptr[7];
rv = rv << 8 | ptr[6];
rv = rv << 8 | ptr[5];
rv = rv << 8 | ptr[4];
rv = rv << 8 | ptr[3];
rv = rv << 8 | ptr[2];
rv = rv << 8 | ptr[1];
rv = rv << 8 | ptr[0];
return rv;
}
#endif
And of course internally
structs are used and are the preferred "C" way.