This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: SetupXP


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]