Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 64 bit design

Reply
Thread Tools

64 bit design

 
 
Balban
Guest
Posts: n/a
 
      10-15-2010
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
 
Reply With Quote
 
 
 
 
Michael Schumacher
Guest
Posts: n/a
 
      10-15-2010
Balban wrote:

> 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
64-bit Windows. You may find this paper <http://linkpin.de/sbkuqf>
helpful, as it discusses this topic in depth.

> 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      10-15-2010
Balban <(E-Mail Removed)> writes:
> 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?

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the point of having 16 bit colour if a computer monitor can only display 8 bit colour? How do you edit 16 bit colour when you can only see 8 bit? Scotius Digital Photography 6 07-13-2010 03:33 AM
Reversing Bit Order.. i.e. MSB becomes bit 0, LSB becomes bit 15 benn686@hotmail.com C++ 9 08-22-2007 12:13 AM
"LoadLibrary" of a 32 bit so with 64 bit java on a 64 bit machine markryde@gmail.com Java 3 01-19-2007 10:30 PM
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit, Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new ! vvcd Computer Support 0 09-17-2004 08:15 PM
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit,Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new! Ionizer Computer Support 1 01-01-2004 07:27 PM



Advertisments