SDL_Event's use of Unions

Hello everyone.

I’ve been working on creating a C#/.NET wrapper for SDL 1.3. Yes there is a wrapper already, but it uses 1.2.

I have everything working in Mono, but in .NET it complains and fails due to the work around to make unions work in .NET.
I only see two ways of making it work.

  1. Create a wrapper for the Event structure in C or C++ and statically link SDL to that wrapper, and then load the produced DLL into .NET
  2. See if the SDL team has an idea for putting a wrapper in place within SDL itself.

In Mono I have native access to the Event structure which means I don’t have to call any PtrToStruct function. I believe that helps with performance, but I haven’t gotten to profiling and optimization yet.

Anyway, if there can be a discussion about it, throw ideas out there, and so on if possible. If I can get it to work in both Mono and .NET I’ll make it public and support it for as long as I can.

Thanks in advance!

  • Micah

PS: in case any are wondering why I would even think to use C# with SDL, it’s because my professional work has me working strictly with C# so it seemed reasonable to me. In a virtualized Linux using Mono I was getting a consistent 60 fps (vsync) So it’s my hope that the .NET nonsense won’t slow it down much if at all.

[…]

Can’t help with the actual question, but…

PS: in case any are wondering why I would even think to use C# with SDL,
it’s because my professional work has me working strictly with C# so it
seemed reasonable to me. In a virtualized Linux using Mono I was getting
a consistent 60 fps (vsync) So it’s my hope that the .NET nonsense won’t
slow it down much if at all.

Depends on what you’re doing, but basically, it comes down to this old 30/70
rule, which is perhaps more like 10/90 or even 5/95, if you use OpenGL or
Direct3D, and exclude custom shaders. That is, 5% of the code runs 95% of the
time, making the “raw code performance” of those 95% almost irrelevant.

Meanwhile, high level optimization (ie better data structures and smarter
algorithms) is where the big performance leaps are to be found - and high
level languages generally make that easier and safer to do.

So, using a nice, safe high level language can definitely be a good idea, even
for performance critical applications.On Monday 22 August 2011, at 23.56.18, “MBrening” <micah.brening at gmail.com> wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

David Olofson wrote:> On Monday 22 August 2011, at 23.56.18, “MBrening” <@Micah_Brening> wrote:

[…]

Can’t help with the actual question, but…

PS: in case any are wondering why I would even think to use C# with SDL,
it’s because my professional work has me working strictly with C# so it
seemed reasonable to me. In a virtualized Linux using Mono I was getting
a consistent 60 fps (vsync) So it’s my hope that the .NET nonsense won’t
slow it down much if at all.

Depends on what you’re doing, but basically, it comes down to this old 30/70
rule, which is perhaps more like 10/90 or even 5/95, if you use OpenGL or
Direct3D, and exclude custom shaders. That is, 5% of the code runs 95% of the
time, making the “raw code performance” of those 95% almost irrelevant.

Meanwhile, high level optimization (ie better data structures and smarter
algorithms) is where the big performance leaps are to be found - and high
level languages generally make that easier and safer to do.

So, using a nice, safe high level language can definitely be a good idea, even
for performance critical applications.


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’


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

Regarding the issue, I think that something as simple as passing an event structure pointer to a function and having it return a structure from the union would work. Like SDL_GetEventMotion(Event *e) Or something like that. But I see that as only being helpful for getting it to work with C#. I’m just stubborn and don’t want to give up on the project since I got so much done already :slight_smile:

I agree with your statement about it being like 5/95. I didn’t notice any speed difference from the test I developed in C# compared to the similar tests in C and C++. Even with all the hand-holding C# does it didn’t seem to slow it down. But then it was a very minimalistic test.

I should also point out I got my wrapper working with SDL_ttf, SDL_Mixer, and SDL_Image. I think supporting SDL_net would be simple to implement, I just didn’t see a need since there are sockets in C#. If I am able to get the Event issue worked out then I’d “port” other helper libs.

I guess the worst case scenario is that I implement my own Event class that uses SDL_EventState. Cache previous values and then on a Poll grab the new values and compare with the old and fire off events.

[…]

Regarding the issue, I think that something as simple as passing an event
structure pointer to a function and having it return a structure from the
union would work. Like SDL_GetEventMotion(Event *e) Or something like
that. But I see that as only being helpful for getting it to work with
C#. I’m just stubborn and don’t want to give up on the project since I
got so much done already :slight_smile:

I’m not sure how you’re going about this, but in general, one solves these
kind of issues by implementing part (or all) of the foreign language binding
in the native language of the API. This can often be automated to some extent.

So, in this case, you’d implement your own SDL_GetEventMotion(Event *e) in C,
and have the C# side of the binding (or C# applications directly) calling
that.

Another option would be to rework the event interface to something more
suitable for a proper high level language. In my SDL binding for EEL, an event
is simply a ‘table’ (an associative array, that is) containing the fields that
are relevant for the event type at hand. It would probably make sense to do
something like that in most dynamic languages.

There is more tricky business down the road, though. Callbacks is one API
design that can be nasty to interface to, especially from languages running on
a VM of some sort, and even more so when the calls are made from other
threads, “interrupt” context or worse, a real time context such as an audio
I/O thread. One way is to handle it via IPC and some sort of messages/events,
but that’s obviously a problem in realtime applications. One thing to keep in
mind when designing new APIs for C/C++ engines and libs. :slight_smile:

I agree with your statement about it being like 5/95. I didn’t notice any
speed difference from the test I developed in C# compared to the similar
tests in C and C++. Even with all the hand-holding C# does it didn’t seem
to slow it down. But then it was a very minimalistic test.

In the game I’m working on right now, Kobo II, I’m dealing with physics and AI
for literally hundreds of enemies, everything processed at a fixed 100 Hz
logic frame rate, and it’s mostly written in EEL, which currently runs on a
"pure" VM without JIT, so it’s probably a lot slower than C#.

Even so, performance issues are not anywhere near the “once per object, every
frame” level, but rather “hundreds of times per object…”, like rendering
particle explosions all in OpenGL 1.1 style code. Or the na?ve all-to-all
collission testing that the current physics engine is doing. :smiley: That part is
actually written in C, and still maxes out at only some 600 objects on a
single 3 GHz core - but that’s 18 million tests per second! Some basic spatial
partitioning, and one could handle a few thousand objects in pure EEL code.

Of course, whenever you have “too much” power, you come up with all sorts of
fun stuff to do with it - but that’s where friendly high level languages come
in handy again: You can actually try a lot of that stuff real time, in-game,
without spending unreasonable amounts of time hacking and debugging prototype
code.On Wednesday 24 August 2011, at 17.22.21, “MBrening” <micah.brening at gmail.com> wrote:


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

David Olofson wrote:> On Wednesday 24 August 2011, at 17.22.21, “MBrening” <@Micah_Brening> wrote:

[…]

Regarding the issue, I think that something as simple as passing an event
structure pointer to a function and having it return a structure from the
union would work. Like SDL_GetEventMotion(Event *e) Or something like
that. But I see that as only being helpful for getting it to work with
C#. I’m just stubborn and don’t want to give up on the project since I
got so much done already :slight_smile:

I’m not sure how you’re going about this, but in general, one solves these
kind of issues by implementing part (or all) of the foreign language binding
in the native language of the API. This can often be automated to some extent.

So, in this case, you’d implement your own SDL_GetEventMotion(Event *e) in C,
and have the C# side of the binding (or C# applications directly) calling
that.

Another option would be to rework the event interface to something more
suitable for a proper high level language. In my SDL binding for EEL, an event
is simply a ‘table’ (an associative array, that is) containing the fields that
are relevant for the event type at hand. It would probably make sense to do
something like that in most dynamic languages.

There is more tricky business down the road, though. Callbacks is one API
design that can be nasty to interface to, especially from languages running on
a VM of some sort, and even more so when the calls are made from other
threads, “interrupt” context or worse, a real time context such as an audio
I/O thread. One way is to handle it via IPC and some sort of messages/events,
but that’s obviously a problem in realtime applications. One thing to keep in
mind when designing new APIs for C/C++ engines and libs. :slight_smile:

I agree with your statement about it being like 5/95. I didn’t notice any
speed difference from the test I developed in C# compared to the similar
tests in C and C++. Even with all the hand-holding C# does it didn’t seem
to slow it down. But then it was a very minimalistic test.

In the game I’m working on right now, Kobo II, I’m dealing with physics and AI
for literally hundreds of enemies, everything processed at a fixed 100 Hz
logic frame rate, and it’s mostly written in EEL, which currently runs on a
"pure" VM without JIT, so it’s probably a lot slower than C#.

Even so, performance issues are not anywhere near the “once per object, every
frame” level, but rather “hundreds of times per object…”, like rendering
particle explosions all in OpenGL 1.1 style code. Or the na?ve all-to-all
collission testing that the current physics engine is doing. :smiley: That part is
actually written in C, and still maxes out at only some 600 objects on a
single 3 GHz core - but that’s 18 million tests per second! Some basic spatial
partitioning, and one could handle a few thousand objects in pure EEL code.

Of course, whenever you have “too much” power, you come up with all sorts of
fun stuff to do with it - but that’s where friendly high level languages come
in handy again: You can actually try a lot of that stuff real time, in-game,
without spending unreasonable amounts of time hacking and debugging prototype
code.


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’


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

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.

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!

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)?> 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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Patrick Baggett wrote:

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)?
?

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
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://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.

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

Cheers,

AndreOn 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.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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

The C spec only cares that sizeof (short) <= sizeof (int) <= sizeof
(long)…it’s not true that, universally, 64-bit platforms have a sizeof
(whatever) equal to anything.

On gcc for x86 linux, int is 4 bytes, long is 4.
On gcc for amd64 linux, int is 4 bytes, long is 8.
On MSVC for both x86 and amd64 windows, int is 4 bytes, long is 4.

–ryan.

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

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 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.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
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

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


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

MBrening wrote:

Hello everyone.

I’ve been working on creating a C#/.NET wrapper for SDL 1.3. Yes there is a wrapper already, but it uses 1.2.

I have everything working in Mono, but in .NET it complains and fails due to the work around to make unions work in .NET.
I only see two ways of making it work.

  1. Create a wrapper for the Event structure in C or C++ and statically link SDL to that wrapper, and then load the produced DLL into .NET

Your best bet is to make an empty event class, with a different subclass for each event type; and a factory function in Managed C++ code to create the event from an SDL_Event. When fetching an event from SDL, just pass the event structure into this factory to get the appropriate event class instance. Should be simple enough.

PS: in case any are wondering why I would even think to use C# with SDL, it’s because my professional work has me working strictly with C# so it seemed reasonable to me. In a virtualized Linux using Mono I was getting a consistent 60 fps (vsync) So it’s my hope that the .NET nonsense won’t slow it down much if at all.

Generally speaking, .NET outperforms Mono.

PS: Forest Hale, some Unixes use ILP64 instead of LP64; so sizeof(int)==8 may be true there. Also, on 16-bit machines, sizeof(int)==2 IIRC.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

Message: 2
Message-ID: <4E55E863.1090600 at ghdigital.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

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.

Message: 4
Message-ID: <1314255014.m2f.29958 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

snip

PS: Forest Hale, some Unixes use ILP64 instead of LP64; so sizeof(int)==8 may be true there. Also, on 16-bit machines, sizeof(int)==2 IIRC.

The actual answer to “what’s the size of an int?” is a little more
complex than that.

Way back when (and even now), BCPL (which C was indirectly derived
from, via B) had only one basic data type: the word (I don’t know
about advanced data types, such as structs). Words were, specifically,
the size of your machine’s native data size (a 16 bit processor used
16 bit words, a 32 bit processor used 32 bit words, etc.).

When C was first created, the basic model was that it’s data types
were an expansion of BCPL’s data types, so the ‘default’ type (int)
was the same size as BCPL’s only data type. This is why setjump() and
longjmp() work with ints instead of pointers: when they were first
created, ints were expected to be the same size as pointers. Some old
code apparently reflects this.

The actual definition of an int has nothing to do with it’s sizeof()
size, but instead to it’s range of values: an int must AT A MINIMUM be
able to store any value between -32767 and +32767 (for example, an int
on a machine that doesn’t support data sizes smaller than 48 bits
would probably be the same size as a char: 48 bits). There is,
however, no maximum allowed range of values, so any size of int that
fulfills the range requirements is actually legal.

Now, theoretically this all means that ints should be sized according
to the processor, and code that treats ints as pointers would stand to
benefit from this, but other code treats ints as having a fixed size,
raising the question: what do you do when your machine gets an
expansion in it’s native data size? The usual solution seems to be
that you issue an ABI specification for that platform that specifies
the size of an int; I understand the usual size to be “the size we’re
used to it being”.

If you want specific sizes, then you should use stdint.h, and never
the ‘generic’ types like int. It’s simple good practice and should
become expected. stdint isn’t part of C++ yet, but it hopefully will
be in the next standard, and it isn’t especially difficult to write
anyways.> Date: Wed, 24 Aug 2011 23:14:59 -0700

From: Forest Hale
To: SDL Development List
Subject: Re: [SDL] SDL_Event’s use of Unions
Date: Wed, 24 Aug 2011 23:50:14 -0700
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL_Event’s use of Unions

Hi,

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.

SDL has pragma pack(push,4)/pack(pop) when the compiler is MSVC (and I
think also for Borland ones):

Here:

malkia ~/p/sdl $ hg grep “#pragma” | grep pack
include/begin_code.h:5535:#pragma nopackwarning
include/begin_code.h:5535:#pragma pack(push,4)
include/close_code.h:5535:#pragma nopackwarning
include/close_code.h:5535:#pragma pack(pop)

This was not done for other systems, or compilers for the same system.
I even posted a message just week ago about it - 15 August 2011, named
"#pragma pack(push, 4) (msvc) question"

I have my own pure FFI bindings through luajit, and I had to remove the
packings, because I’d rather stay with the defaults.

People replied to me, that this was done, because certain MSVC .vcproj
options might’ve affected it, but I’m not so sure about it. It sounded
like something was broken probably long time ago, and since fixed.

Cheers,
Dimiter “malkia” Stanev.> It’s that or else a difference between Mono and .NET.


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

SDL has pragma pack(push,4)/pack(pop) when the compiler is MSVC (and I
think also for Borland ones):

Are people still calling it the Borland compiler, despite the fact that Borland isdead andtheir dev tools have been owned by Embarcadero for over 3 years now?>From: “Dimiter “malkia” Stanev”

Subject: Re: [SDL] SDL_Event’s use of Unions

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. :)On Thu, Aug 25, 2011 at 9:30 AM, Mason Wheeler wrote:

Are people still calling it the Borland compiler, despite the fact that
Borland is dead and their dev tools have been owned by Embarcadero for over
3 years now?

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.


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

NO! You are ALL WRONG! Haha, sorry, I wanted to join in the fight.

It’s possible the compiler on windows is 32bits. I’m using MSVS 2010. I used that to compile SDL. I changed the target from 32 to 64, but I don’t know if that really makes a difference.

From all the comments on here, I take it that relying on sizeof() to always be consistent for each type is not possible. So that means it’s time to dig through documentation regarding the C# preprocessor. Joy!

Thanks for all the info. I’ll see what I can hammer out. I’ll post the link when I get something somewhat consistent.

PS: Forest Hale, some Unixes use ILP64 instead of LP64; so sizeof(int)==8
may be true there. Also, on 16-bit machines, sizeof(int)==2 IIRC.

Proof or it didn’t happen. :wink:

Seriously though, pretty much every “mainstream” OS uses sizeof(int) == 4.
We’re talking Linux, *BSD, Solaris (SPARC/x86), Mac OS, Windows, IRIX,
HP-UX, AIX, QNX, etc. That probably covers 99.9% (if not 100%) of
compiler/platforms found on desktops and servers. And I have compiled C for
all of them. You might be able to find some bass ackwards UNIX from early on
that this did not hold on, but it doesn’t exist now so the point is rather
moot.

Yes, I think we’re all aware of what the C standard says about sizeof(short)
<= sizeof(int) <= sizeof(long). This is the theory. The practice is
generally that sizeof(short) == 2, sizeof(int) == 4, sizeof(long) == { 4, 8
}. You can, in theory, stray from this and still be legal C. In practice,
the other 99.99% of C code already written, will fail. There is so
much
inertia behind the current sizes that straying from them is basically
a death sentence for your compiler/platform, which is why it isn’t done. No,
it isn’t written into the standard, but at this point it might as well be.
And it makes sense that it is this way. Nobody wants to write:

short x = 0x100;

and get that 0x100 is too large to fit in a short. Nobody wants to do file
I/O using fixed length types only to find that they can’t convert from a
fixed length type back to a short/int/long safely because some stupid
compiler writer decided to do sizeof(short) = sizeof(int) = sizeof(long) =
2. If you can make absolutely 0 assumptions about your program (let’s say,
everytime you typed GCC, it randomly assigned sizes to short/int/long that
maintained the required sizeof order), then all you can use is fixed length
types, and then your code looks like crap, you have to type underbars for
every variable (tedious), and you have stupid short/int/long types that are
useless for anything at all. Sorry, but I’d much rather have a 99.9% chance
that my assumptions are correct, and leave the “but my int is 6 bytes” kind
of platforms in the dust. Weirdness doesn’t pay. Divergence from industry
accepted practices doesn’t pay.

If you’re running on some tiny 8-bit or 16-bit microcontroller, you might be
able to find sizeof(int) < 4, but let’s face it, they aren’t going to be
running software like SDL, UNIX, or really anything that wasn’t explicitly
written for them when they have < 1MB of address space.
So please, stop bringing up the mythical/theoretical ILP64 platforms. They
don’t really exist. I can tell you right now that none of the platforms
above use it.

If you see sizeof(int) == 8, check again, and make sure it isn’t structure
padding. sizeof(struct) is not the same as sizeof(struct.parts).

Patrick Baggett wrote:

If you see sizeof(int) == 8, check again, and make sure it isn’t structure padding. sizeof(struct) is not the same as sizeof(struct.parts).

Sorry everyone. "measure twice, cut once."
As everyone kept insisting, sizeof(int)==4 on both my Lin64 and Win64. The issue must have been a difference between .NET and Mono. Both were being given the same data layout, same spacing and everything. .NET required strict definition of the structure’s layout. Mono had issues with the strict definition and it worked perfect without it.

Anyway, thanks for all the support!

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.

Sigh If I could afford to retire I just might spend time to use SDL to write
a PDP11 emulator, complete with blinkin’ lights :slight_smile:

JeffOn 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: