You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Doug MacEachern <do...@covalent.net> on 2001/12/18 06:23:46 UTC
PerlIOAPR_tell problem found
the problem is that since we rip out largefile flags on the modperl side,
Off_t is 4 bytes (16 bit int), whereas on the perl side Off_t is 8 bytes
(64 bit int). for testing, add the largefile flags (as reported by
perl -V:ccflags_uselargefiles) like the diff below.
we could solve this on the modperl side by re-enabling largefile flags for
apr_perlio.c only. but then when Apache::PerlIO gets implemented (to
replace tie *STD{IN,OUT}), we cannot since it will change the sizeof
request_rec. if perl were to change to something that is always 64 bit
int (like NV), we'd be ok in both cases (i think).
diff -u -r1.4 apr_perlio.c
--- xs/APR/PerlIO/apr_perlio.c 2001/12/18 01:13:15 1.4
+++ xs/APR/PerlIO/apr_perlio.c 2001/12/18 05:12:31
@@ -1,3 +1,5 @@
+#define _LARGEFILE_SOURCE
+#define _FILE_OFFSET_BITS 64
#include "mod_perl.h"
#include "apr_perlio.h"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIOAPR_tell problem found
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 18 Dec 2001, Stas Bekman wrote:
> So shell we put your last temp patch in before we get this done, and
> turn the todo sub-test normal? Or should we just get the ground ready
> for Apache::PerlIO?
can't just put the patch in since flags will be different on certain
platforms. and for optimal performance with ithreads, one would disable
largefile support in perl. anyhow, there is a workaround in now.
> Also what happens if we want to use some of the perlio features in core?
the only thing we need to be careful of is when a function of ours that
returns Off_t is called by perl. so inside libmodperl.so or outside, we'd
need the same #include modperl_largefiles.h in the file that contains the
Off_t return and not in files that dereference the request_rec.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIOAPR_tell problem found
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Tue, 18 Dec 2001, Stas Bekman wrote:
>
> correction from my last message: 4 bytes is a 32 bit int
>
>
>>So is this a p5p call?
>>
>
> i doubt p5p would go for it, but if you want to ask, go for it.
I can I'll ask while following up on my bug report.
> we can work around it, even for Apache::PerlIO. we can generate a
> modperl_largefile.h that defines the ripped out largefile flags, #include
> that in apr_perlio.c then for Apache::PerlIO, just have two .c files, one
> that implements all the PerlIO table functions (like apr_perlio.c)
and one
> that dereferences the request_rec when needed (without largefile flags
> enable).
So shell we put your last temp patch in before we get this done, and
turn the todo sub-test normal? Or should we just get the ground ready
for Apache::PerlIO?
Also what happens if we want to use some of the perlio features in core?
using the optional functions won't help if the .so wasn't loaded. Is
there a way to make PerlIO a part of the core library, while it can be
still used without modperl? I guess that's one of the linker solutions
you've proposed when I've originally asked about how to use perlio in
Apache::SubProcess.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIOAPR_tell problem found
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 18 Dec 2001, Stas Bekman wrote:
correction from my last message: 4 bytes is a 32 bit int
> So is this a p5p call?
i doubt p5p would go for it, but if you want to ask, go for it.
we can work around it, even for Apache::PerlIO. we can generate a
modperl_largefile.h that defines the ripped out largefile flags, #include
that in apr_perlio.c then for Apache::PerlIO, just have two .c files, one
that implements all the PerlIO table functions (like apr_perlio.c) and one
that dereferences the request_rec when needed (without largefile flags
enable).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: PerlIOAPR_tell problem found
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> the problem is that since we rip out largefile flags on the modperl side,
> Off_t is 4 bytes (16 bit int), whereas on the perl side Off_t is 8 bytes
> (64 bit int). for testing, add the largefile flags (as reported by
> perl -V:ccflags_uselargefiles) like the diff below.
> we could solve this on the modperl side by re-enabling largefile flags for
> apr_perlio.c only. but then when Apache::PerlIO gets implemented (to
> replace tie *STD{IN,OUT}), we cannot since it will change the sizeof
> request_rec. if perl were to change to something that is always 64 bit
> int (like NV), we'd be ok in both cases (i think).
>
> diff -u -r1.4 apr_perlio.c
> --- xs/APR/PerlIO/apr_perlio.c 2001/12/18 01:13:15 1.4
> +++ xs/APR/PerlIO/apr_perlio.c 2001/12/18 05:12:31
> @@ -1,3 +1,5 @@
> +#define _LARGEFILE_SOURCE
> +#define _FILE_OFFSET_BITS 64
>
> #include "mod_perl.h"
> #include "apr_perlio.h"
Cool, that works for me.
So is this a p5p call?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org