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