httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: core dump in ap_send_fd
Date Fri, 21 Dec 2001 07:30:21 GMT
From: "Stas Bekman" <>
Sent: Friday, December 21, 2001 12:14 AM

> > In the meanwhile, you need to use the buckets directly.
> > It's only four lines of code as opposed to one.
> > 
> > apr_bucket_brigade *bb = apr_brigade_create(r->pool);
> > apr_bucket *b = apr_bucket_pipe_create(thepipe);
> > ap_pass_brigade(bb);
> can I use this for sending an opened file as well? given that I've a fd 
> already opened from Perl. I use ap_os_file_put to convert it into 
> apr_file_t.

That is most certainly not portable.  Win32, particularly, has alternate
semantics for opening files as 'sendfile ready'.  Passing in an fd [which
would be a HANDLE on win32] isn't send-file-able.

> > Um, why would you ever do that and expect it to work?  I mean, I guess we
> > could theoretically check the length you pass in against the length of the
> > file, but that goes against the
> > we-expect-the-caller-to-pass-us-sane-arguments mentality that we typically
> > maintain around here.
> Well, I don't think it is normal to dump core if some of the arguments is not proper,

> especially in this case where it's just the count that can be wrong. But that bothers
me less, 
> if you think it's fine to core dump, rather than cleanly exit with an error message :)

Where are we going with this, to the win32-friendly and safe api?  <eyeballs rolling>

Seriously, we've made a very consiencious decision in APR not to check safety
on user args.  

If mod-perl needs to be the 'safe and simple' solution - it will need to wrap
up perl with arg checking itself.  This is simply not compatible with anyone's
vision of APR performance.  We have enough arguments over debug-asserts, that
I doubt we will take the hit on an fstat() just to see if the coder had a clue
about what they were doing.

View raw message