Date: Wed, 24 Feb 1999 13:12:05 -0500 (EST)
From: John Bley <jbb6@acpub.duke.edu>
To: new-httpd@apache.org
cc: gstein@lyra.org
Subject: Re: [PATCH] Many, many nits in modules
Message-ID: <Pine.SOL.3.91.990224125039.15062A@soc13.acpub.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

[CC'ed to gstein@lyra.org, I would appreciate CC's in responses since I 
don't subscribe to new-httpd]

Greg Stein says:

> > 99% of these are the list-stopper { NULL }s for handler_recs and
> > command_recs, but there was one outlier in mod_so.c, where somebody had
> > forgotten that the fixer_upper function pointer existed.  If this patch
> > isn't accepted I'll resend a patch for that outlier, since it feels funny.

> Why go thru all that, when C says that NULLs are automatically filled
> in? If a new member is added to a structure, you'll just need to go and 
> retrofit all those initializers again.

... Which is one of the reasons I dislike non-programmatic static 
initializers...

Anyway, to defend the patch, yes, ANSI C says that the runtime 
environment should ensure that the struct be filled in with 0 and NULL.

But, those aren't always the right choices.

Consider part of the patch:
-	NULL
+	NULL, NULL, NULL, OR_NONE, NO_ARGS, NULL

NO_ARGS doesn't have an underlying representation of 0: it's the 7th 
element of enum cmd_how.  It's fairly unlikely, but if somebody decides 
to accept command_structs with NULL names and sees that this (last) one 
accepts "RAW_ARGS" (the first member of the enum), that code could break.

Or, consider that cut-n-paste coding in mod_so.c led to this:
    NULL,			/* type_checker */
+   NULL,			/* fixer_upper */
    NULL,			/* logger */
It's fairly unlikely that somebody would have wanted to go in and set up 
a proper "logger" pointer, but if they had, it would have been registered as
the fixer_upper pointer instead.  Ouch, what a debugging headache.  "My 
method's not even being called!"

It's better to be precise and wrong than vague and right.

It's mainly a stylistic issue, I guess.  I certainly won't be 
offended if the patch isn't taken.

-- 
John Bley - jbb6@acpub.duke.edu
Duke '99 - English/Computer Science
  Since English is a mess, it maps well onto the problem space,
  which is also a mess, which we call reality.     - Larry Wall