We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1922 - SDL_SetMainReady should not be in a public header
Summary: SDL_SetMainReady should not be in a public header
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: main (show other bugs)
Version: HG 2.0
Hardware: x86 Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-20 03:58 UTC by Vittorio Giovara
Modified: 2013-07-06 03:34 UTC (History)
0 users

See Also:

Attachments
move sdl_setmainready in a more subclass-friendly method (746 bytes, patch)
2013-07-02 20:04 UTC, Vittorio Giovara 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vittorio Giovara 2013-06-20 03:58:08 UTC 
This function is exposed with this disclaimer

*  Calling this yourself without knowing what you're doing can cause
*  crashes and hard to diagnose problems with your application.

In my opinion this situation should be avoided, users are able to generate enough crashes already ;)
Could this be moved in a private header?


Also I find that the calling point in SDL_uikitappdelegate.m is dangerous as the -(void) postFinishLaunch method can be overridden when subclassing.
Could this be moved in inside the init or in the didFinishLaunchingWithOptions method which are always called even when subclassed?


Willing to provide a patch if no objections.
Comment 1 Vittorio Giovara 2013-07-02 20:04:04 UTC 
Created attachment 1203 [details]
move sdl_setmainready in a more subclass-friendly method

here is a patch for the second point
Comment 2 Sam Lantinga 2013-07-06 03:34:29 UTC 
I'm not going to move SDL_SetMainReady(), since I want people to be aware of how main works on various platforms, and it needs to be in public headers to be in the exported symbol table on some platforms.

Your patch for your second point looks good, and it's applied.
http://hg.libsdl.org/SDL/rev/65592096da2d

Thanks!