On Mon, Aug 26, 2013 at 09:18:48PM -0600, Karl Williamson wrote: > These functions are not called by anything in the Perl core, and > cpan.grep.me > > http://grep.cpan.me/?q=PerlIO_v%3Fsprintf > > shows just 4 occurrences, none of which look like they result in actual > calls. They arrived 17 years ago as part of "PerlIO abstraction added": commit 760ac839baf413929cd31cc32ffd6dba6b781a81 Author: Larry Wall <lwall@sems.com> Date: Sat Aug 10 15:24:58 1996 +0000 perl 5.003_02: [no incremental changelog available] diff --git a/Changes b/Changes index 7a8b96b..90175e0 100644 --- a/Changes +++ b/Changes @@ -7,6 +7,47 @@ site, in the .../src/5.0 directory for full version releases, or in the .../src/5/0/unsupported directory for sub-version releases.) +---------------- +Version 5.003_02 +---------------- +o Visible Changes to Core Functionality + - Redefining constant subs, or changing sub's prototype now give warnings. + - Fixes for ++/-- of values close to max/min size of an integer + - Warning for un-qualified bareword as handler in $SIG{}. + - UNIVERSAL::isa can now be called as static method. + +o Changes in Core Internals + - PerlIO abstraction added. + Perl core and standard extensions no longer assume ANSI C's stdio is IO + mechanism, Default Configure mode is still to use stdio via set of C macros + Alternate modes are to use stdio via one perlio.c module, or + to use sfio if available. but unlike the rest of the IO abstraction, they weren't simply wrappers that directed to stdio or sfio. As far as I can work out, they've been tweaked and refactored at various points, but have never actually been used by the core. I suspect that they can go. And given that their presence seems to tempt people to refactor them, they *should* go. I'm not sure if we should flag them with a deprecated attribute, and take them out post v5.20.something, or simply remove them right now on the assumption that no-one is using them. Nicholas ClarkThread Previous | Thread Next