Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 64 bit Endianness issue

Reply
Thread Tools

64 bit Endianness issue

 
 
sureshjayaram@gmail.com
Guest
Posts: n/a
 
      05-12-2006
>This is your problem. Fix it. There are several approaches:

>(1) Fix the function to accept a pointer to size_t.


I may not be able to do because the function is supplied by a
library.

>(2) Copy the size_t into an unsigned int (by assignment), and pass a
> pointer to *THAT*. If the function might change the value pointed


> at, copy it back afterwards. However, you're going to have trouble


> if the value won't FIT in an unsigned int, which itself presents

problems.

This is possible. The value will always fit in unsigned int.

>(3) Change the type of the member to unsigned int.


This is also not possible as the data type definition is provided by
some other library.

 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      05-12-2006
Ian Collins wrote:
> Gordon Burditt wrote:
>>> I have problem with the code only with 64 bit big endian machine.
>>> i have a member size_t val1 in my structure.

>>
>>> The size of size_t is
>>> 32(unsigned int) in 32 bit machines and 64(unsigned long) in 64 bit
>>> machines.

>>
>> I'm not convinced this generalization is valid for all 32-bit or
>> 64-bit machines.
>>

> size_t has to be able to hold the largest size value, so it has to be 64
> bit on a 64 bit system.


Just because the system is 64 bit does not mean the compiler has to
allow you to create a single object with a size that won't fit in a 32
bit size_t. If it doesn't allow you to create such a large object, why
make size_t 64 bits?

>>> I am passing address of this variable to a different function (where it
>>>
>>> accepts only pointer to unsigned int) unsigned int *.

>>
>> This is your problem. Fix it. There are several approaches:
>>
>> (1) Fix the function to accept a pointer to size_t.
>> (2) Copy the size_t into an unsigned int (by assignment), and pass a
>> pointer to *THAT*. If the function might change the value pointed
>> at, copy it back afterwards. However, you're going to have trouble
>> if the value won't FIT in an unsigned int, which itself presents problems.
>> (3) Change the type of the member to unsigned int.
>>

> Agreed, 1 is the preferred solution.


Agreed.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      05-12-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
> Sorry I did't notice the first part of the previous message. I
> should have provided the context in the first place.


You are obviously unaware of the problems with the foul google
interface to usenet. Read the following sig, and the URLs
referenced in it. Do so before posting again.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>


 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      05-12-2006
>>>I have problem with the code only with 64 bit big endian machine.
>>>i have a member size_t val1 in my structure.

>>
>>
>>>The size of size_t is
>>>32(unsigned int) in 32 bit machines and 64(unsigned long) in 64 bit
>>>machines.

>>
>>
>> I'm not convinced this generalization is valid for all 32-bit or
>> 64-bit machines.
>>

>size_t has to be able to hold the largest size value, so it has to be 64
>bit on a 64 bit system.


No, it doesn't. It could be 10240 bits, or a whole bunch of values
all >= 64 bits.

There is also the possibility that this is a smegmented architecture,
with the maximum size of a smegment (and therefore an object) being
2**32. This is the case for the Intel x86 large-code (32 bits),
small-data (16 bits) model where size_t is 16 bits.


How is a N-bit system defined again? I thought a system was N-bit
if an int had N bits. In that case, this 64-bit machine with a
64-bit unsigned long and a 32-bit unsigned int ISN'T a 64-bit machine.

Other possible definitions include:
- The width of a code pointer.
- The width of a data pointer.
(Note: the above two can be different. See "medium" and "compact" models
on an Intel [2345]86. Note that a Pentium can be considered a 48-bit
machine by this definition.)
- The value given in marketing literature (in which case it's
meaningless).
- The width of the memory data bus (in which case machines like the
8088 and 8086 have different bittedness but virtually identical
software architecture.)

Gordon L. Burditt
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-12-2006
Flash Gordon wrote:
> Ian Collins wrote:
>
>> Gordon Burditt wrote:
>>
>>>> I have problem with the code only with 64 bit big endian machine.
>>>> i have a member size_t val1 in my structure.
>>>
>>>
>>>> The size of size_t is
>>>> 32(unsigned int) in 32 bit machines and 64(unsigned long) in 64 bit
>>>> machines.
>>>
>>>
>>> I'm not convinced this generalization is valid for all 32-bit or
>>> 64-bit machines.
>>>

>> size_t has to be able to hold the largest size value, so it has to be 64
>> bit on a 64 bit system.

>
>
> Just because the system is 64 bit does not mean the compiler has to
> allow you to create a single object with a size that won't fit in a 32
> bit size_t. If it doesn't allow you to create such a large object, why
> make size_t 64 bits?
>

Are you aware of such a system?

--
Ian Collins.
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      05-12-2006
Gordon Burditt wrote:

<snip>

> (Note: the above two can be different. See "medium" and "compact" models
> on an Intel [2345]86. Note that a Pentium can be considered a 48-bit
> machine by this definition.)
> - The value given in marketing literature (in which case it's
> meaningless).
> - The width of the memory data bus (in which case machines like the
> 8088 and 8086 have different bittedness but virtually identical
> software architecture.)


You should have picked the 80386SX and 30386DX (IIRC) where the SX had a
16 bit data bus (so it could more easily be used in circuits designed
for a 286) and the DX had a 32 bit data bus but they had *identical*
instruction sets.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      05-12-2006
>> Just because the system is 64 bit does not mean the compiler has to
>> allow you to create a single object with a size that won't fit in a 32
>> bit size_t. If it doesn't allow you to create such a large object, why
>> make size_t 64 bits?
>>

>Are you aware of such a system?


Well, there's one that's close: Intel Pentium in 32-bit mode.
(People seem to mean that an N-bit system has N *address* bits. In
the original posting, if bittedness is determined by the size of
int, a 64-bit system with a 32-bit unsigned int *ISN'T* 64 bits).
The pointers are 48 bits, but they are segmented, and the largest
segment is 4G.

Going down in size a bit, consider Intel Pentium in 16-bit mode
large model. The largest object is 64k, although pointers are
32-bits. size_t is 16 bits. You *can* do funky things with pointer
arithmetic to carry into the segment, but that's called "huge model".

Gordon L. Burditt
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-12-2006
Gordon Burditt wrote:
>>>Just because the system is 64 bit does not mean the compiler has to
>>>allow you to create a single object with a size that won't fit in a 32
>>>bit size_t. If it doesn't allow you to create such a large object, why
>>>make size_t 64 bits?
>>>

>>
>>Are you aware of such a system?

>
>
> Well, there's one that's close: Intel Pentium in 32-bit mode.
> (People seem to mean that an N-bit system has N *address* bits. In
> the original posting, if bittedness is determined by the size of
> int, a 64-bit system with a 32-bit unsigned int *ISN'T* 64 bits).
> The pointers are 48 bits, but they are segmented, and the largest
> segment is 4G.
>
> Going down in size a bit, consider Intel Pentium in 16-bit mode
> large model. The largest object is 64k, although pointers are
> 32-bits. size_t is 16 bits. You *can* do funky things with pointer
> arithmetic to carry into the segment, but that's called "huge model".
>

I've spent many a happy hour tinkering with Intel's segmented
architecture, but I'm not aware of any current 64 bit system that would
use a 32 bit size_t.

--
Ian Collins.
 
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
endianness and 64-bit machines bob_jenkins@burtleburtle.net C Programming 7 05-20-2006 01:46 PM
Bit shifts and endianness gamehack C Programming 72 01-11-2006 06:01 AM
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