SDL_Event's use of Unions

SDL Development
21

There are 4 different 64-bit models

64-bit data models

Dmodel short int long long2* ptr/size_t OS--------------------------------------------------------------------
LLP64/
IL32P64 16 32 32 64 64 Microsoft Windows

LP64/
I32LP64 16 32 64 64 64 Most Unix and Unix**

ILP64 16 64 64 64 64 HAL Computer***

SILP64 64 64 64 64 64 Unicos

  • long2 is “long long”
    ** Most Unix and Unix-like systems, e.g. Solaris, Linux, and Mac OS X
    *** HAL Computer Systems port of Solaris to SPARC64

On 8/24/2011 11:14 PM, Forest Hale wrote:

Let me make this extremely clear:
sizeof(int) == 4

Doom, Quake, Quake2, Quake3 and many other codebases assume this as law.

What weird platform have you found that has a different sizeof for int?

I even recall someone telling me that gcc enforces this rule on all
architectures.

On 08/24/2011 11:06 PM, Ian Norton wrote:

I’ve ran onto this issue when trying to write cross
Platform c# wrappers.

http://stackoverflow.com/questions/5591421/handling-different-unmanaged-integer-sizes

The problem comes when using long, on all windows platforms and on
32bit Linux, this is 32 bits. On 64bit Linux it is 64bits.

On 25 Aug 2011, at 01:17, Andre Leiradella <andre at leiradella.com <mailto:andre at leiradella.com>> wrote:

On a 64-bit compiler, sizeof( int ) == 8 on any OS. You’re probably
using a 32-bit compiler on Windows.

Cheers,

Andre

On 24/08/2011 18:15, MBrening wrote:

Patrick Baggett wrote:

Quote:

This post can be marked as closed (not that you can here.)
I was able to get the union to work. It turned out some of the
substructures used Strings. I switched to IntPtr and it compiled fine.

However, I ran into an funny issue. On Linux64 sizeof(int)=8. On
Win64 sizeof(int)=4. That was throwing off the Surface structure. So
I have to do an ugly conditional compilation. But it is working.

That’s really odd. I’ve never seen sizeof(int) == 8, and I can’t
even think of a C/C++ compiler that implements an int as 64-bits
because there is so much code that assumes sizeof(int)==4. Are you
sure it isn’t sizeof(long int)?

Quote:
As promised, I’ll set up a site and work on developing it further,
perhaps wrapper classes to make it more OO.
If anyone has any ideas, suggestions, requests please feel free to
contact me.
Cheers!

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I didn’t run the sizeof code. When I set up the binding from C# to
C, on windows I had to explicitly state the sizes of the ints to 4
bytes. When I tried the same code on Linux it complained left
and right. I switched it to see the ints as 8 bytes and it worked
great. Maybe GCC does some padding that VisualC doesn’t? Maybe with
it being a 64bit Linux it aligns data to 8bytes rather than 4.
The size would still be 4, but there’d be padding. shrug that’s my
best guess.

It’s that or else a difference between Mono and .NET.

SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

22

ANYWAY, one can easily avoid integer size issues by using stdint.h or SDL’s integer types (Int32, Uint32, etc); or in the case of C# and Managed C++, using CTS integer types (System.Int32, System.Uint32, etc)------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

23

That’s not enough.

Structure packing introduced a different problem for 64-bit platforms in
SDL:

For example the next few structures would pack differently in
MSVC/BORLANDC/METROWERKS than GCC(mingw,cygwin,etc).

Ryan said that he would look into that.

But here are few examples.

typedef struct SDL_UserEvent
{
Uint32 type; /< ::SDL_USEREVENT through ::SDL_NUMEVENTS-1 */
Uint32 windowID; /< The associated window if any */
int code; /< User defined event code */
void *data1; /< User defined data pointer */
void *data2; /**< User defined data pointer */
} SDL_UserEvent;

So data1 with pragma pack(4) would end up 12 position in 64-bit MSVC
(pragma pack(4) is enforced in SDL’s begin_code.h), and in 16 position
with gcc.

And then you have to match the same behaviour in your FFI bindings
(.NET, luajit, D, etc.). Often it would work, as people using .NET more
likely are using MSVC, but it’s not unlikely for .NET and mingw - here
you go it won’t work.

Other structures in SDL that might be affected (just cursory browsing
through the header files)

typedef struct SDL_SysWMEvent
{
Uint32 type; /< ::SDL_SYSWMEVENT */
SDL_SysWMmsg *msg; /< driver dependent data, defined in
SDL_syswm.h */
} SDL_SysWMEvent;

typedef struct SDL_Overlay
{
Uint32 format; /< Read-only */
int w, h; /< Read-only */
int planes; /< Read-only */
Uint16 *pitches; /< Read-only */
//// omitted
} SDL_Overlay;On 8/25/2011 7:57 PM, Nathaniel J Fries wrote:

ANYWAY, one can easily avoid integer size issues by using stdint.h or
SDL’s integer types (Int32, Uint32, etc); or in the case of C# and
Managed C++, using CTS integer types (System.Int32, System.Uint32, etc)

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

24

Dimiter ‘malkia’ Stanev wrote:

That’s not enough.

Structure packing introduced a different problem for 64-bit platforms in
SDL:

For example the next few structures would pack differently in
MSVC/BORLANDC/METROWERKS than GCC(mingw,cygwin,etc).

Ryan said that he would look into that.

I wasn’t talking about packing, just the integer problem. Structure packing is something I avoid religiously.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

25

No specifics, but as I understand it, people who don’t want to spend
money from their budget to replace the old hardware/software, since
the operating and maintenance costs come out of someone else’s budget.
There is some specialized hardware involved though, it’s not a simple
barebones replacement. Still, job security isn’t necessarily a bad
thing.

-JustinOn Thu, Aug 25, 2011 at 9:20 PM, Jeff Post <j_post at pacbell.net> wrote:

On Thursday 25 August 2011 07:00, Justin Coleman wrote:

Some of us are still using the Borland compiler and tools from 2002,
so yes. Hell, I’m happy when I get to deal with that rather than the
PDP11 machines I support. :slight_smile:

Holy cow! That brings back fond memories. I’m curious though, other than
nostalgic hobbyists, who would still be using PDP11s these days? A 486
machine can outperform a PDP11 at a fraction of what it costs just for the
electricity to run an old DEC machine.