Nick Ing-Simmons wrote:
Steve Hay <[EMAIL PROTECTED]> writes:It's a good point, but this code is only destined for Windows platforms so I can get away with that.
My wrapper function now looks broadly like:No - I think the code above is now fine.
FILE *f;
PerlIO *p;
f = library_func(file, mode);
// Force binary mode for underlying FILE *.
PerlLIO_setmode(PerlSIO_fileno(f), O_BINARY);
// Import FILE * to PerlIO *.
p = PerlIO_importFILE(f, mode);
// Push translation layer on PerlIO if required.
if (strchr(mode, 'b') == NULL)
PerlIO_binmode(p, type, O_TEXT, ":crlf");
// Now store PerlIO in used-supplied glob ref...
This works perfectly under my Perl without PERL_IMPLICIT_SYS enabled (including the example quoted above), but I still have the same problem with PerlIO_binmode() that I reported previously when building against a Perl with PERL_IMPLICIT_SYS enabled: "different types for formal and actual parameter" 1, 2 and 4, and "too few actual parameters".
Why does the PerlIO_binmode() in the outline of my wrapper function above cause a problem? Is it something that I'm doing wrong,
The only question I have is whether you realy want to do CRLF translation if you run this on UNIX and user just asks for "w" without a "b".
perlio.c only does that if O_TEXT != O_BINARY so UNIX etc will not do CRLF.
I'll keep an eye out for changes in this area in the future, but I've actually found a way around the problem now: my XS wrapper function is itself wrapped by a Perl function back in the .pm file in my module, and I can easily do the binmode() call there instead of using PerlIO_binmode() in the XS.or a teething problem with stdio/PerlIO co-existence in ActivePerl that I can't do anything about in my code?I think that is it - it seems that PERL_IMPLICIT_SYS parts of XSUB.h need some work.
This also has the added advantage that it works under Perl 5.6.x -- those versions don't have a PerlIO_binmode() as far as I can see.
Thanks again for all the help.
Steve
