develooper Front page | perl.perl5.porters | Postings from October 2001


Thread Next
Nicholas Clark
October 29, 2001 13:52
Message ID:
Should PerlIOBuf_dup be prototyped so that other layers can derive from it?
Something like this:

--- perliol.h.orig	Mon Oct 22 00:26:34 2001
+++ perliol.h	Mon Oct 29 21:32:55 2001
@@ -158,6 +158,7 @@
 			      const char *mode, int fd, int imode,
 			      int perm, PerlIO *old, int narg, SV **args);
 extern IV PerlIOBuf_pushed(PerlIO *f, const char *mode, SV *arg);
+extern PerlIO *PerlIOBuf_dup(pTHX_ PerlIO *f, PerlIO *o, CLONE_PARAMS *param);
 extern SSize_t PerlIOBuf_read(PerlIO *f, void *vbuf, Size_t count);
 extern SSize_t PerlIOBuf_unread(PerlIO *f, const void *vbuf, Size_t count);
 extern SSize_t PerlIOBuf_write(PerlIO *f, const void *vbuf, Size_t count);

Also, pod/perliol.pod doesn't mention the dup entry. [sorry, no patch for

Also, was a conclusion reached on whether PerlIO_apply_layera (and therefore
the supporting PerlIO list functions) could/should be part of the public
layer API?

Also, I believe that PerlIO is still not behaving as documented - open with
a layer that fails to push doesn't fail the open. However, I can't see an
easy way to write a regression test for the core that demonstrates this
misbehaviour, short of a PerlIO::test layer that can be instructed to fail
in specified ways.

Nicholas Clark

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