On Tue, Dec 17, 2013 at 2:58 PM, Karl Williamson <public@khwilliamson.com> 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 > PERLIO_NOT_STDIO=undef sets PERLIO_NOT_STDIO=PERL_CORE > > 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 <http://perl5.git.perl.org/perl.git/commit/f7e7eb72c805f1b630a3d1a32ed33c0f6da60bea>. The following post by the author of PerlIO may clarify somewhat (though there's not a very detailed rationale): <http://www.nntp.perl.org/group/perl.perl5.porters/2001/01/msg28376.html>. 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