Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definition of symbol NONAMELESSUNION causes trouble #565

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Definition of symbol NONAMELESSUNION causes trouble #565

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 1.2.14
Reported for operating system, platform: Windows (All), All

Comments on the original bug report:

On 2010-04-23 15:43:14 +0000, Volker Grabsch wrote:

The windx5 video driver defines the NONAMELESSUNION symbol before including <ddraw.h>, but only if GNUC is defined:

#ifdef GNUC
#define NONAMELESSUNION
#endif

This is simply not necessary, as the GNU compilers already supports unnamed unions.

Moreover, defining this symbol even causes trouble in some MinGW configurations, depending on which set of DirectX headers one uses.

There are some sets that requires NONAMELESSUNION to be defined before the first "#include <windows.h>", not just before the first "#include <ddraw.h>". In those cases, the rest of SDL will compile under the assumption that unions are named, but the headers still define unnamed unions, which leads to compiling errors. Recently, that caused a lot of trouble in the mingw-cross-env project.

Long story short: Defining NONAMELESSUNION is unneeded and does more harm than good, so I recommend to remove it.

The attached patch does exactly that.

On 2010-04-25 01:14:50 +0000, Volker Grabsch wrote:

Created attachment 507
remove the trouble causing definition of NONAMELESSUNION

On 2010-07-18 10:51:58 +0000, Sam Lantinga wrote:

This is fixed in revision 134c6707b767, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant