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

Re: What are PerlIO_sprintf and PerlIO_vsprintf for?

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
August 30, 2013 16:01
Subject:
Re: What are PerlIO_sprintf and PerlIO_vsprintf for?
Message ID:
20130830160115.GY66035@plum.flirble.org
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 Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About