64 bit design

[Balban]

Hello,

I wrote some piece of software that mostly assumes 32 bit systems. I
defined types such as u32, u64. The general convention I use has been
always to use int or unsigned int, and when I use a pointer for
arithmetic I use unsigned long (I never target 16 bit and this is
mostly safe on 32bit/64bit systems), and I use u32, u64 only when I am
sure that the type has to be that size.

Now, If I move to a 64 bit system, what precautions should I consider
to support my software?

One issue is the API that I provide. Consider this function prototype:

int my_api_call(unsigned int type, unsigned int flags);

There are API functions like this and most of them take flags in an
unsigned int. If I passed arguments in u64 today, it would mean
passing too much data in 32 bit sysems. If I continue to pass unsigned
int, the flags provided in 0-31 would be fine on both systems, but I
won't be able to pass anything on 32 onwards in a 32 bit system. Is
there good way to design this right from the start?

Thanks,

Bahadir

 

[Michael Schumacher]

I wrote some piece of software that mostly assumes 32 bit systems. I
defined types such as u32, u64. The general convention I use has been
always to use int or unsigned int, and when I use a pointer for
arithmetic I use unsigned long (I never target 16 bit and this is
mostly safe on 32bit/64bit systems), and I use u32, u64 only when I am
sure that the type has to be that size.

Now, If I move to a 64 bit system, what precautions should I consider
to support my software?

Using "unsigned long" for pointer arithmetic may lead to unpleasant
results on 64-bit systems, depending on the data model (LLP64, LP64,
SILP64) they implement. To be safe, you should rather use variables
of type size_t/unintptr_t and ptrdiff_t/intptr_t for array indexing
and pointer arithmetic. For example, "unsigned long" will work on
both 32- and 64-bit Linux and Unix systems, but fail (silently!) on

One issue is the API that I provide. Consider this function prototype:

int my_api_call(unsigned int type, unsigned int flags);

There are API functions like this and most of them take flags in an
unsigned int. If I passed arguments in u64 today, it would mean
passing too much data in 32 bit sysems. If I continue to pass unsigned
int, the flags provided in 0-31 would be fine on both systems, but I
won't be able to pass anything on 32 onwards in a 32 bit system. Is
there good way to design this right from the start?

Merely using a 32-bit system doesn't also mean that the type "int" will
use 32 bits: a C compiler for that system may well choose to implement
16-bit integers. The C standard defines various types (in <stdint.h>)
such as "uint32_t" that should be used to write portable code.


Cheers,
mike

 

[Keith Thompson]

I wrote some piece of software that mostly assumes 32 bit systems. I
defined types such as u32, u64. The general convention I use has been
always to use int or unsigned int, and when I use a pointer for
arithmetic I use unsigned long (I never target 16 bit and this is
mostly safe on 32bit/64bit systems), and I use u32, u64 only when I am
sure that the type has to be that size.

[...]

What exactly do you mean by "when I use a pointer for arithmetic
I use unsigned long"?

I've seen code that converts a pointer to an integer performs
arithmetic on the integer, and then converts back to a pointer.
If you're doing that, don't. It's non-portable and unnecessary.
Just perform arithmetic on the pointer value itself.

If you just mean that you're adding or subtracting unsigned long
values to pointer values, that's probably ok -- but it might make
more sense to use size_t.

Can you show us some examples?