Date: Wed, 9 Jul 1997 09:53:41 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: [PATCH] PR#344: 64-bit cleanup
In-Reply-To: <Pine.LNX.3.95.970709111054.8863A-100000@aardvark.ukweb.com>
Message-ID: <Pine.LNX.3.95dg3.970709095315.19469H-100000@twinlark.arctic.org>
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

All the XtOffsetOf() are integers, used by set_string_slot and it's kin.

Dean

On Wed, 9 Jul 1997, Paul Sutton wrote:

> On Tue, 8 Jul 1997, Dean Gaudet wrote:
> > Introduce a new type generic_data which is large enough to hold a pointer
> > or an integer, and which the compiler is likely to pass by value
> > efficiently.  This requires certain functions that take "void *" to start
> > taking generic_data.  It also changes the command_rec and related
> > structures to include a generic_data field instead of a void * field.
> 
> +1 on providing a generic data type where a variable can take both
> pointer and integer value.
> 
> But does the cmd_data field really need to take both int and pointers? As
> far as I can see it only takes pointer values, or boolean (which is
> clearly representable in any sized pointer). The only place it appears to
> take multiple int values is mod_dir, with things like BY_PATH. But even
> they are defined as pointers to (fake) variables. I think that having a
> single value to hold both int and pointer values is generally an evilness,
> so I would prefer to _define_ the cmd_info field of the directive
> definitions as a pointer in the API, and not define it as a generic data
> type. Is there any module which is actually using it to store int values? 
> 
> //pcs
> 
>