FAR * in 64-bit machines

[pendell]

I am attempting to port a 32-bit application to a 64-bit Itanium
processor architecture.

One of the problems I am having is FAR * declarations are being
rejected by the compiler as "incompatible size". I am assuming that
FAR * is a 32-bit or so call that is inadequate on a 64-bit machine.

What do I need to declare a FAR pointer on a 64-bit machine to be?
FAR FAR? long FAR? REAL REAL FAR? Somebody throw me a bone here.

Many thanks.

Respectfully,

Brian P.

 

[Ben Pfaff]

I am attempting to port a 32-bit application to a 64-bit Itanium
processor architecture.

One of the problems I am having is FAR * declarations are being
rejected by the compiler as "incompatible size". I am assuming that
FAR * is a 32-bit or so call that is inadequate on a 64-bit machine.

What do I need to declare a FAR pointer on a 64-bit machine to be?
FAR FAR? long FAR? REAL REAL FAR? Somebody throw me a bone here.

FAR is not part of the standard C language. It is some kind of
extension provided by your compiler vendor. You will have to
consult a newsgroup that discusses your vendor's compiler.

 

[xarax]

FAR is not part of the standard C language. It is some kind of
extension provided by your compiler vendor. You will have to
consult a newsgroup that discusses your vendor's compiler.

Isn't LP64 a standard specification for 64-bit
pointers and integers? If so, then we can talk
about how a conforming implementation would
deal with 64-bit pointers.

 

[Josh Sebastian]

Isn't LP64 a standard specification for 64-bit
pointers and integers? If so, then we can talk
about how a conforming implementation would
deal with 64-bit pointers.

From what I could glean from Google
(http://www.opengroup.org/public/tech/aspen/lp64_wp.htm), LP64 is not a
standard but merely a description of a certain way of implementing a
64-bit system (specifically, long and pointers being 64 bits wide while
int is smaller). As such, it would be on-topic to discuss the consequences
of compiling code for an LP64 system (eg, "That call to memmove would
result in UB if long were 64 bits wide"). However, the OP's question was
not about an LP64 system. It seems to me that the OP was asking about a
system where there are various sizes for pointers (akin to the old DOS
apps), and specifically he was asking about an extension to a particular
compiler which allows one to utilize said feature.

Josh

 

[Barry Schwarz]

snip

Isn't LP64 a standard specification for 64-bit
pointers and integers? If so, then we can talk
about how a conforming implementation would
deal with 64-bit pointers.

No, it is not.

The string LP64 does not appear anywhere in n869, the last public
draft of the standard, and it is unlikely it was added at the last
minute.


<<Remove the del for email>>

 

[Dan Pop]

Isn't LP64 a standard specification for 64-bit
pointers and integers? If so, then we can talk
about how a conforming implementation would
deal with 64-bit pointers.

Nope, LP64 is not a requirement for a conforming implementation any more
than ILP32 is. A 64-bit implementation could very well use the IL32P64
model without having its conformance affected. That's precisely why
C99 has introduced the long long type which is required to have at least
64 bits.

Given Microsoft's past track record, I would be very surprised if the
type long is 64 bits on its Itanium implementation.

Dan

 

[pendell]

Right ... so I need to consult my vendor (HP, in this case). So it's
not a standard part of the C language. Nuts... for some reason I
thought it was.

Thanks anyway.

Respectfully,

Brian P.

 

[Jan Engelhardt]

I am attempting to port a 32-bit application to a 64-bit Itanium

Right ... so I need to consult my vendor (HP, in this case).

far (and "near") was (is) something used in the 16-bit DOS environment,
to do some fancy segment operations.

However, this came pretty obsolete when 32-bit was introduced, and
is only there to provide compatibility. gcc doesnot even recognize these
keywords.