You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <re...@ibm.net> on 1998/10/28 03:16:29 UTC

Type casting int to pointer and back again

The cmd_data field in command_rec (http_config.c) is declared as a
void*.   In all cases I am aware of, cmd_data is used as an int (see
DirectoryMatch directive in http_core.c, for example).  This is making
getting a clean port to AS/400 a real pain in the butt because ints and
pointers have different sizes and the compiler does not allow casting an
int to a pointer (casting a pointer to an int is okay).  Regardless of
the AS/400 problems,  using pointers and ints interchangeably is not
good form and we should change it, IMO.

One solution would be to change the void * to an int. This solution is
more restrictive (only have an int to play with, not a struct) and would
break any third party modules that use cmd_data as a pointer. A  better
solution might be to keep cmd_data as a void* and make changes to
http_core to use the field as a pointer (to ints). Thoughts?

Bill Stoddard
stoddard@raleigh.ibm.com




Re: Type casting int to pointer and back again

Posted by James Morris <jm...@intercode.com.au>.
On Tue, 27 Oct 1998, Bill Stoddard wrote:

> One solution would be to change the void * to an int. This solution is
> more restrictive (only have an int to play with, not a struct) and would
> break any third party modules that use cmd_data as a pointer. A  better
> solution might be to keep cmd_data as a void* and make changes to
> http_core to use the field as a pointer (to ints). Thoughts?

I wonder if it might be worth looking at the type casting facilities used
by GTK+ (www.gtk.org) as an example for a general solution.

- James.
--
James Morris
<jm...@intercode.com.au>          



Re: Type casting int to pointer and back again

Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 27 Oct 1998, Bill Stoddard wrote:

> The cmd_data field in command_rec (http_config.c) is declared as a
> void*.   In all cases I am aware of, cmd_data is used as an int (see
> DirectoryMatch directive in http_core.c, for example).  This is making
> getting a clean port to AS/400 a real pain in the butt because ints and
> pointers have different sizes and the compiler does not allow casting an
> int to a pointer (casting a pointer to an int is okay).  Regardless of
> the AS/400 problems,  using pointers and ints interchangeably is not
> good form and we should change it, IMO.

Look at mod_autoindex, it hacks up an enum using pointers.

The pointers and ints aren't used interchangeably, it's up to the called
routine to make some sense out of its argument.

> One solution would be to change the void * to an int. This solution is
> more restrictive (only have an int to play with, not a struct) and would
> break any third party modules that use cmd_data as a pointer. A  better
> solution might be to keep cmd_data as a void* and make changes to
> http_core to use the field as a pointer (to ints). Thoughts?

So then all cases where an int is used you'll declare a static const int
and insert the address to it?  What a pain.  But doesn't bother me too
much.

How are you going to deal with the int passed in void * clothing for
ap_note_cleanups_for_fd() ?  You're not going to be able to convince me
it's worth wasting an int of allocated memory just so you can pass a
pointer to it... fds are the most common type of cleanups.  But you could
convince me of this approach: 

in some headerfile somewhere:

extern const char oh_what_a_hack[1];
#define INT_IN_POINTER_CLOTHING(i)	(oh_what_a_hack + (i))
#define INT_WITHOUT_POINTER_CLOTHING(p)	((char *)(p) - oh_what_a_hack)

in alloc.c:

static void fd_cleanup(void *fdv)
{
    close(INT_WITHOUT_POINTER_CLOTHING(fdv));
}

API_EXPORT(void) ap_note_cleanups_for_fd(pool *p, int fd)
{
    ap_register_cleanup(p, INT_IN_POINTER_CLOTHING(fd), fd_cleanup, fd_cleanup);
}

API_EXPORT(void) ap_kill_cleanups_for_fd(pool *p, int fd)
{
    ap_kill_cleanup(p, INT_IN_POINTER_CLOTHING(fd), fd_cleanup);
}

The pointer is never dereferenced, so this doesn't violate any rule I
know of.

The contents of oh_what_a_hack are irrelevant...

You can use that to fix the config stuff too.

Dean