On Sun, Apr 04, 2004 at 09:51:38PM -0700, Stas Bekman wrote:
Geoffrey Young wrote:
you mean that -D_FILE_OFFSET_BITS=64 ought to be stripped from $perl_cflags and perl recompiled, not that mod_perl can get away with simply not including that value when it itself is compiled. if it were stripped only in mod_perl compilation you would have conflicting definitions of off_t in the two sources - long long in perl and int in mod_perl/APR.
No Joe is talking about mod_perl only. It's not a problem to use perl and mod_perl mismatching as long as we don't interface apis which use off_t, like seek(). In which case we croak, just as before. The logic here didn't change.
Actually, I am surprised that mod_perl can get away with stripping -D_F_O_B=64 from the Perl cflags, but it seems like it can.
If there are any places in the Perl C API where an Off_t is taken, Perl will be passed a long when it was expecting a long long in this case: so there are potential problems here.
Hmmm... looks like the PerlIOBuf structure has an Off_t in it, so using that in mod_perl could be problematic. In general on x86 maybe you just get away with the long vs long long mismatch in passed vs expected function arguments/return values.
The only time we have the problem is when passing arguments between functions operating on off_t and similar arguments. Most of the time this doesn't happen. Only in APR perlio layers we had to disallow seek on non-zero arguments if there is a conflict. (probably also in Apache::PerlIO, but I doubt anybody is going to seek on STD streams, which is it used for).
We don't use PerlIOBuf, but a subclass of it in Apache::PerlIO and APR::PerlIO layer. This subclass directly calls apache/apr io functions, without doing any buffering. On the Perl side everything comes down to PerlIO_write, whose proto:
Perl_PerlIO_write(pTHX_ PerlIO *f, const void *vbuf, Size_t count)
and Size_t < off_t.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
