From: "Stas Bekman" <[EMAIL PROTECTED]> 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); > > APR_BRIGADE_INSERT_TAIL(bb, b); > > 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.
