Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
over-riding "unsigned long" size
30 views
Skip to first unread message
pedr...@lycos.com
Jul 18, 2016, 7:41:11 AM7/18/16
to
In linux, long is 32-bits for 32-bit OS or 64-bits for 64-bit OS.
This causes problems for an old package, because included X11 header
has typdef unsigned long.
There are many places where the size would require extra switch-case
clauses to handle 32 or 64 bits. Hundreds of source files would
need to be scrutinised. Simply hacking the X11 header file
to change long to int makes the problem go away, but it not really
best practice.
So I hoped some compiler options could change "long" size.
Now in fortran, one can generally over-ride variable size with
compiler flags, but c++ does not seem so well endowed.
The only thing I know of is -m32 which generates old 32-bit code and
forces "long" to 32 bits. GNU compiler has -mx32 which utilises
extra 64-bit instruction set, but limits "long" to 32 bits.
Intel compiler does not have this.
Any other workarounds?
This causes problems for an old package, because included X11 header
has typdef unsigned long.
There are many places where the size would require extra switch-case
clauses to handle 32 or 64 bits. Hundreds of source files would
need to be scrutinised. Simply hacking the X11 header file
to change long to int makes the problem go away, but it not really
best practice.
So I hoped some compiler options could change "long" size.
Now in fortran, one can generally over-ride variable size with
compiler flags, but c++ does not seem so well endowed.
The only thing I know of is -m32 which generates old 32-bit code and
forces "long" to 32 bits. GNU compiler has -mx32 which utilises
extra 64-bit instruction set, but limits "long" to 32 bits.
Intel compiler does not have this.
Any other workarounds?
Ian Collins
Jul 18, 2016, 8:03:12 AM7/18/16
to
--
Ian
Nobody
Jul 18, 2016, 4:28:23 PM7/18/16
to
On Mon, 18 Jul 2016 04:40:14 -0700, pedro1492 wrote:
> In linux, long is 32-bits for 32-bit OS or 64-bits for 64-bit OS. This
> causes problems for an old package, because included X11 header has typdef
> unsigned long.
> There are many places where the size would require extra switch-case
> clauses to handle 32 or 64 bits. Hundreds of source files would need to
> be scrutinised. Simply hacking the X11 header file to change long to int
> makes the problem go away, but it not really best practice.
> So I hoped some compiler options could change "long" size.
The main problem with this is that if you include any headers for other
> In linux, long is 32-bits for 32-bit OS or 64-bits for 64-bit OS. This
> causes problems for an old package, because included X11 header has typdef
> unsigned long.
> There are many places where the size would require extra switch-case
> clauses to handle 32 or 64 bits. Hundreds of source files would need to
> be scrutinised. Simply hacking the X11 header file to change long to int
> makes the problem go away, but it not really best practice.
> So I hoped some compiler options could change "long" size.
libraries, you need to link against versions of those libraries which were
built with a 32-bit "long".
In general, client code communicates with Xlib using the platform's base
types (e.g. int or long), whatever those happen to be. In situations where
data is being passed from the client to the server without any conversion,
you'd normally use the fixed-size types CARD8, CARD16 and CARD32. Most
"handle" types (e.g. XID, Atom) are aliases for CARD32, i.e. they'll be
32-bit regardless of the size of "long".
0 new messages