This is the mail archive of the cygwin-patches@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: [PATCH] setup.exe: Stop NetIO_HTTP from treating entire streamas a header


On Wed, 2001-11-28 at 10:52, Christopher Faylor wrote:
> On Tue, Nov 27, 2001 at 05:40:22PM -0600, Gary R Van Sickle wrote:
> >> On Wed, Nov 28, 2001 at 09:12:20AM +1100, Robert Collins wrote:
> >> >On Wed, 2001-11-28 at 05:42, Christopher Faylor wrote:
> >> Regardless, I strenuously disagree with this.  It certainly is not
> >> deprecated in the Cygwin DLL.
> >
> >I'm with Chris on this one, again from a self-documenting standpoint if
> >nothing else.

Answering both Gary and Chris..
 
> Yes, that's my primary motivation.  Basically, it was the way I was
> taught and the reasons for doing it that way were drilled into my
> head.

For C I agree completely. In C I am religious about using NULL for
pointers. 
 
> I used to really object to stuff like this, too:
... 	   ...
> which is what started this thread.  I used to inform everyone who worked
> for me not to do this.  Then I had to work on Cygwin where this
> construction is rampant.  And, I believe that it is even mentioned in
> the GNU coding standard.

I must revisit that soon :].
 
> So, my new internal rule is that the above is ok but foo != 0 is
> "wrong".

Why? I parse (foo) and if (foo != 0) are the same IFF foo is a simple
type (which includes pointers to objects). if (foo != NULL) is the same
as these two IFF foo is a pointer to an object. So NULL is a special
case, and thats useful in C, with it's relatively weak type checking.
C++ however has much stronger type checking, so I don't see the value in
a manual extra check like that. 

> When I test a character, I use c != '\0' and when I test a floating
> point value, I do f != 0.0.

Which is wrong BTW. To test floating point you want (abs (f) > confidence). 
 
> Btw, is google actually faster if someone else has just done the same
> search?  :-)

AFAIK, no. The query may not end up on the same server, so caching won't
impact it. Google has seriously distributed processing going on :].

Rob


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