Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-Id: <4.3.1.2.20011106121122.0224af30@pop.ma.ultranet.com> X-Sender: lhall AT pop DOT ma DOT ultranet DOT com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 06 Nov 2001 12:25:05 -0500 To: Pavel Tsekov , cygwin AT cygwin DOT com From: "Larry Hall (RFK Partners, Inc)" Subject: Re: [PATCH proposal] Re: Setup use on win2k - a me too ... In-Reply-To: <3BE8189E.E1E8BD5A@syntrex.com> References: <1005045929 DOT 5221 DOT 0 DOT camel AT lifelesswks> <3BE7CA86 DOT 2EBAC42D AT syntrex DOT com> <3BE7DFE6 DOT E8062434 AT syntrex DOT com> <1005052267 DOT 2726 DOT 19 DOT camel AT lifelesswks> <20011106113645 DOT B8509 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:06 PM 11/6/2001, Pavel Tsekov wrote: >Christopher Faylor wrote: > > > > On Wed, Nov 07, 2001 at 12:11:06AM +1100, Robert Collins wrote: > > >On Wed, 2001-11-07 at 00:04, Pavel Tsekov wrote: > > >> Btw what is done in state.cc is a bad habbit, IMO. > > > > > >Yes. It's C style, not CPP style. > > > > > >I'll approve this if you do a patch and Changelog. > > > > > >NULL for everything is correct - source should be 0, as should > > >net_method etc. the current code has checks for 0/NULL, but not for > > >random values :]. > > > > > >And trust_level should be deleted if not used. > > > > It is not a bad habit to rely on global variables being 0. If they > > aren't then something is seriously wrong with either 'ld' or the > > run-time the loader. > > > > The linux kernel developers have actually been removing explicit > > initialization to zero from most of their globals and statics. I've > > been doing the same thing inside of the DLL. It creates a smaller > > executable since the variables end up being assigned to the BSS segment > > which is allocated at run-time and is guaranteed to be zero. > > > > I don't think that gratuitous changes like this are really called for > > unless you can *really* show that global variables are pointing to > > non-zero memory. If that is the case then we need to figure out how > > that could possibly be the case. > >I didn't know this actually, so I thought it may the cause for the >problem. >In fact I now remember that I red in the "Design & Implentation of 4.4 >BSD" >that when the zeroing of BSS was disabled at some stage of the >development >this caused a of lot problems with the available programs and this >feature was >thrown away. However the MSVC compiled programs do not have globals, >except >the static ones, initialized to zero and I was fooled by the fact. > >I apologize for this. I'm not sure that apologies are necessary. I, for one, believe that Chris' statement about zeroing out globals is important in it's scope but shouldn't be taken too far. Obviously, to be portable, adding the explicit initialization to 0 is important. Although gcc/ld may not require this, other compiler suites may (as you pointed out) and code, in general, can't assume too much about the compiler being used. For Linux, Cygwin, and setup (as well as others I'm sure), this assumption is safe and valid. For others, it may not be. Personally, I'm of the notion that the ability to optimize away such "inefficiencies" as initializing a global to 0 should be part of compiler suites. Then, it becomes a non-issue. The compiler would do the optimization as required even if the explicit initialization is done. However, since we have to live in the real world with things as they are, we have to make concessions. ;-) I just wanted to make this point so that someone doesn't get the wrong impression about initializing globals to 0. And no apologies are necessary for not knowing about an obscure optimization feature of a compiler suite. :-) Larry Hall lhall AT rfk DOT com RFK Partners, Inc. http://www.rfk.com 118 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/