develooper Front page | perl.perl5.porters | Postings from March 2000

RE: Source filters

Thread Previous | Thread Next
Marquess,P,Paul,NEL38 R
March 24, 2000 11:37
RE: Source filters
Message ID:
From: Gurusamy Sarathy []
> On Fri, 24 Mar 2000 11:51:15 GMT, "Moore, Paul" wrote:
> >If so, there are some problems with Filter-1.17 when used with a Perl
> >with MULTI/ITHREADS/IMP_SYS on Win32. Specifically, the filter callback
> >functions seem to be missing the appropriate scattering of pTHXo_ in the
> >declarations. I've attached a patch for this.
> It needs a more complete patch than that.  See below.

Thanks Sarathy, I'll try to upload a new version to CPAN this weekend with
the patch included. The only change I'll add is to make it work on pre-pTHX*
Perls and pre-ANSI C compilers.

> >However there are still test failures. 
> >
> >t/call fails with errors which look related to binmode scripts (test 24
> >failing and it uses filter_read_exact, which may be going wrong because
> >line has an extra character (CR) beyond what is expected.
> >t/decrypt, t/order and t/tee fail as well, which may be similar.
> >Worse are t/cpp, t/exec and t/sh, which crash Perl. I can't see why.

Don't you run win95 Paul? If so it is probably the use of shell
metacharacters in the test harness.

> >
> >I think the binmode scripts thing is going to be a nasty portability
> >problem. IMHO, the user of the Filter module should not have to worry
> >line ending conventions in scripts. Of course, if the filter is slurping
> >binary data and translating it, binmode is necessary (that's why it was
> >introduced, for byteloader). Maybe the filter module needs something in
> >API to request binmode or textmode input of the script (with textmode the
> >default, as I expect the majority of filters will be text-based).
> I disagree.  See ByteLoader.  It would be the job of the particular filter
> implementation to know whether it wants to filter "text" or "binary"
> and behave accordingly.
> I think Filter::Util::Call could use some convenience switches
> to do s/\r$// in filter_read() or ignore CRs when counting characters
> in filter_read_exact().  But I don't think it's really that big a
> portability issue if it can be clearly documented.
> >This is starting to look hard...
> The attached patch makes Filter 1.16 pass all tests on Windows, assuming
> you have GNU cpp.exe and tr.exe installed.  It fails test 24 on Linux,
> for reasons that aren't clear.  I haven't investigated much, but it
> seems that it could be a bug in either Filter (buffering issue?) or
> stdio.  The problem that causes the failure is that the initial read
> from filter_read_exact() in test 24 doesn't return nine characters
> like it is supposed to.  Instead it returns only two.

Hmmm, I haven't had a chance to build 5.6.0 yet, but 5.6.0-RC[123] passed
test 24 on my Linux box. I'll check it out once I get 5.6.0 built.
> I haven't checked Filter 1.17, but IIRC it only had documentation
> updates, so this patch should apply there too.  (Note to PMQS: Filter
> should probably require/strongly recommend Perl 5.6.0 on Windows.


> Earlier versions of Perl are suboptimal, owing to the fact that
> PL_rsfp wasn't opened in binmode().)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About