SetupXP
Gary R. Van Sickle
g.r.vansickle@worldnet.att.net
Sat Jul 19 01:32:00 GMT 2003
[snip]
> >> Perhaps we can compromize on "Cygwin Setup -
> >> CurrentTitleOfPage"?
> >
> > That would probably work. I've seen one installer that did that, and I
> see
> > that my Platform SDK help browser thing does that too.
>
> OK, I'll put together a patch+ChangeLog for this tonight (GMTDT, i.e. +1)
> unless you beat me to it.
>
Looks like I didn't ;-).
> >> "make LogFile::exit() not exit if exit_code == 0":
> >> I don't understand the reasoning behind this change. Can you explain?
> >
> > This is one small step for man towards moving the app's exit()ing and UI
> > interaction out of the LogFile class. I'm only changing the success (==0)
> > case currently because there's only one code path that succeeds, while
> there
> > are several places in the code (and in the UI) that do this:
> > "LogSingleton::GetInstance().exit(1);". Eliminating those will require
> more
> > extensive changes.
>
> Wait! The status quo must remain, until we have confirmed evidence that
> static destructors do always run on exit from -mno-cygwin programs.
As Rob said, he's said that too. What am I missing? Neither of LogFile's nor
LogSingleton's destructors do anything, and this change doesn't remove the
"theLog->exit (0);" at the end of main() (the only place its' called with 0),
so... where's the connection?
> Then and
> *only* then can we move to using simple CRT exit().
Um... too late, that's exactly what LogFile::exit() does already. Or, I'm not
advocating replacing LogSingleton::GetInstance().exit(1)'s with ::exit(1)'s, if
that's what you're thinking.
> Until then I don't think
> there is any harm in using constructs like
> LogSingleton::GetInstance().exit(1).
>
Well, the harm is mainly in its use spreading. The longer it sits, the more
entrenched it will become, and the larger the patch required to fix it.
--
Gary R. Van Sickle
Brewer. Patriot.
More information about the Cygwin-apps
mailing list