Benjamin Deutsch <ben <at> fictiongroup.de> wrote:
> I see two problems with this (we might as well discuss this now,
> instead of at patching time):
> 
> 1) Most apps on Windows need this feature, since Windows has no
> easily accessible standard IO otherwise. Therefore, it makes sense
> to have redirection enabled by default.

This reasoning is wrong for many reasons.
- The linker settings one would intuitively use under MinGW give a 
program that will spawn a console if needed, and *also* redirect 
stdio. There exists no combination of linker settings such that it 
spawns a console and doesn't redirect stdio.
- Win32 apps which are launched from a command prompt have accessible 
stdio, even if they don't spawn their own console when executed 
elsewhere. In other words, the accessibility of stdio is exactly the 
same as on Linux, where SDL never redirects.
- stdio redirection is a portability problem; it affects only 
Windows, and only on some compilers/compiler settings, so it's likely 
to turn up as an unpleasant surprise.
- The stdout.txt and stderr.txt the program produces are added to the 
current working directory, rather than the directory the executable 
is in. In addition to filesystem clutter, this means that programs 
with stdio redirection can't run setuid or setgid (yes, you can do 
that under Windows) because that would allow you to create files in, 
say, /Cygwin/etc/profile.d and leave trojans for other users.
- stdout.txt and stderr.txt may be created even if nothing is written 
into them, needlessly cluttering the filesystem.

> 2) Backwards compatibility. An unchanged app from before the patch
> should behave the same.
> 
> The best solution that I can see, given the two assumptions above,
> is to add a function SDL_RedirectStdIO(int flag), which can be
> used to turn the redirection on or off, and have it *on* by
> default. 
> 
> While we're at it, let's add another state (on, off, auto), where
> 'auto' behaves like originally (i.e. platform dependant), and 'on'
> and 'off' force redirection on or off regardless of platform. This
> way the call actually "adds value" 
> 
> (Optionally, a way to change the filenames, or specify only
> partial redirection. This may be easier on the command line or
> application shortcut.)
> 
> Am I correct in assuming, though, that such a function would have
> to be called *before* SDL_Init ? That might make things a bit
> awkward. 

No, it's much worse than that. The current behavior is to do the 
redirect in WinMain (provided by -lSDLmain), before calling main(), 
not in SDL_Init(). Meaning that even if there were a function to turn 
it off, by the time you can call it it's already too late - closing 
stdout is, as far as I can tell, irreversible. In other words, 
allowing anyone to disable the stdio redirect from a source file and 
preserving current behavior are mutually exclusive.

One possibility is to move the redirection into SDL_Init() and 
provide a flag like SDL_INIT_NOSTDIOREDIRECT or 
SDL_INIT_STDIOREDIRECT. However, this means that any output before 
SDL_Init, or output indicating that SDL_Init has failed, will not be 
redirected like before. Another possibility is to just provide a 
function SDL_RedirectStdio() to do the redirection, and have it off 
otherwise.

Another possibility is to provide two different SDLmain libs - one 
with redirect, one without. If the one with redirect was SDLmain and 
the one without was something else, then it would be very awkward for 
Makefiles, since the library options would no longer be platform-
independent. (It might be possible to work around this with something 
like pkg-config --define-STDIO_REDIRECT=0).

I've gone into some lengths above about why stdio redirect is a very 
bad idea. Given that the redirect is done only on Windows, only with 
some linker settings (which fail to match those settings for which 
it's wanted), and that its current implementation is so horrendous, I 
really don't think preserving backwards compatibility should be a 
concern. Note that the stdio redirect is in the static portion of the 
library, not the DLL, so nothing can change without a recompile.

I think providing an SDL_RedirectStdio(const char *stdout_filename, 
const char *stderr_filename) function and disabling redirect 
otherwise is the best solution, because it's the only one which can 
make all platforms consistent. And really, consistency between 
platforms *is* the whole point of SDL.

-- 
CalcRogue: TI-89, TI-92+, PalmOS, Windows and Linux.
http://calcrogue.jimrandomh.org/