develooper Front page | perl.perl5.porters | Postings from December 2013

Re: When do we use PERLIO vs STDIO

Thread Previous
Craig A. Berry
December 17, 2013 21:56
Re: When do we use PERLIO vs STDIO
Message ID:
On Tue, Dec 17, 2013 at 2:58 PM, Karl Williamson
<> wrote:
> I discovered that ext/XS-APItest/APItest.xs is testing the libc functions
> like printf().  We think (on irc) that it is intending to be testing the
> PERLIO equivalents instead.  Does anyone know?
> Looking into how printf becomes a macro that translates into a PerlIO
> function, it happens in the header fakesdio.h, which is currently never
> included, as it happens only if PERLIO_NOT_STDIO is undefined, and by the
> time it is checked, previous code in the including file (perlio.h) has made
> sure that it is defined.
> PERLIO_NOT_STDIO set to 1 means that an error gets generated if an attempt
> is made to use stdio functions; 0 means that both Perlio and stdio are
> enabled, and one has to explicitly use the Perlio functions in order to get
> them.  And "undef" means that the stdio functions automatically are replaced
> by Perlio equivalents.  That all seems reasonable, except that "undef" never
> currently can happen.  Leon summed up the current behavior on irc as:
> PERLIO_NOT_STDIO=0 is the normal mode of operation
> That means that attempts in PERL_CORE to use stdio functions will generate
> errors; but not otherwise.
> So what do we want the general XS writer to get?  What should APItest.xs be
> doing?

I think the intent was to root out uses of stdio in the core but allow
non-core code to mix PerlIO and stdio.  The "undef" option probably
went away in core with
 The following post by the author of PerlIO may clarify somewhat
(though there's not a very detailed rationale):
 What jumped out at me there was, "Undef means USE_PERLIO is not in
use"; undefined USE_PERLIO is not possible anymore is it?

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