httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: general/736: pointers cast as ints of different size - potential memory problems (fwd)
Date Mon, 16 Jun 1997 08:48:54 GMT
I'm not submitting that patch for consideration again, you already
vetoed it.

The functions involved are generally those of the form "here is a
function I want you to call back, and here is a bit of data I want you
to pass to that callback".  In which case calling it generic_data is a
perfect abstraction.

The note_* functions are not callbacks, they reference callbacks.  For
example, using my proposed solution, note_cleanups_for_fd becomes:

void note_cleanups_for_fd (pool *p, ptr_int fd)
    generic_data gd;

    GENERIC_INT (gd) = fd;
    register_cleanup (p, gd, fd_cleanup, fd_cleanup);

Should I go ahead and generate a patch like this?  I'm not going to do it
if you'll veto it.  I'm not sure I completely understand all your issues
with the problem.


On Sun, 15 Jun 1997, Roy T. Fielding wrote:

> >I'd like to revisit this problem.  When I posted my patch I proposed a new
> >type "ptr_int" which is large enough to hold a pointer or an int.  But it
> >was vetoed by Roy because it wasn't "clean enough".  I'd like to submit
> >that the type "int" which we presently use is not an abstraction at all,
> >and is just a convenience and really isn't clean either.
> The problem with your patch was that it changed the interface of general
> functions just because the *completely internal* data type for storing
> the values was changed.  That is the wrong way to go.
> The purpose of the functional interface is to save things for later
> cleanup.  It should therefore have a separate interface for each type
> of thing (modern languages would just use polymorphing, but with C we
> just define separate functions).
> >The remaining alternative that I can think of is to have a table_do_int and
> >a table_do_ptr.  Then we'd need a register_cleanup_int and a
> >register_cleanup_ptr.  And more crap like that.
> The existing use of the table functions is already broken because features
> use it directly instead of through abstract functions.  We already have
> note_cleanups_for_file, note_cleanups_for_fd, and note_cleanups_for_socket
> as interfaces -- any casting or union of data types should be done inside
> those functions.
> >See <> for the
> >example patch using ptr_int that I posted a while back.  That will give you
> >an example of what needs to be changed.
> I would still veto that patch -- an fd is never a pointer, so changing the
> functional interface for the fd routines is breaking an abstraction for
> no good reason.
> ....Roy

View raw message