FAT and long data type

[MB]

Hi,

I'm fairly new to rockbox, I've started browsing the code just to understand how it works. I'm quite puzzled by the use of "long" data type instead of "int". I know the common issue with C data types, but it is quite common to have char = 1 byte, short = 2 bytes, int = 4 bytes. Long are generally "bigger or equal" to int, and can be 40 bits on some architectures, or even 64 bits.
So my question is: are long types used in the FAT code to mean a 32 bit type or something bigger?
Thanks.

[Bagder]

You seem stuck in the 80s! ;-)

In 32bit systems, ints and longs are both 32bits. Ints are only 16 bits on ancient systems, and Rockbox is not adapted to run on such systems. Longs can however be more than 32bits on 64bit archs, and while rockbox runs on no such targets we can build and run simulators on such.

[MB]

Thank you for your reply.

You seem stuck in the 80s! ;-)

Yep, perhaps.. :-)

In 32bit systems, ints and longs are both 32bits. Ints are only 16 bits on ancient systems, and Rockbox is not adapted to run on such systems. Longs can however be more than 32bits on 64bit archs, and while rockbox runs on no such targets we can build and run simulators on such.

As I've said, int=32 bits is fine for me. Now the real question is why use longs in the FAT code. Are they really needed? Shouldn't a int be the same? Instead loking at the code it seems that long is used with a purpose. Now, the problem is that on some systems long=32 bit, while on some others can be 40 or even 64 bits. For example now I am working on a DM642 DSP from TI, the latest compiler supports 64 bit data types, so longs went from 40 bits to 64 bits. Either ways, in the FAT code the 32 bit int seems enough. So why use longs?

[linuxstb]

There was a port (now abandoned and removed from SVN) of Rockbox to an architecture with 16-bit ints and 32-bit longs.  I assume that the FAT driver was changed to use longs as part of the work on that port.  On all current targets (excluding the sims, but they don't use the FAT driver anyway), both long and int are 32-bit.

My opinion is that in somewhere like the FAT driver, where the code is reading/writing binary data, we should be using the int32_t etc family of types where needed, rather than assuming anything about int or long.  But it needs someone who knows the FAT code to go through and clean it up.