develooper Front page | perl.perl5.porters | Postings from September 2011

Re: [perl #100190] RFE: fix sprintf to be consistent with printf andbe useful!

Thread Previous | Thread Next
From:
Brian Fraser
Date:
September 27, 2011 14:06
Subject:
Re: [perl #100190] RFE: fix sprintf to be consistent with printf andbe useful!
Message ID:
CA+nL+naFME3XriRYQO=28HY_4fKc7asBNrr0Z0EQ-myMS7H6eg@mail.gmail.com
On Tue, Sep 27, 2011 at 5:36 PM, Linda Walsh <perlbug-followup@perl.org>wrote:

> # New Ticket Created by  Linda Walsh
> # Please include the string:  [perl #100190]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=100190 >
>
>
>
> This is a bug report for perl from perl-diddler@tlinx.org,
> generated with the help of perlbug 1.39 running under perl 5.12.3.
>
>
> -----------------------------------------------------------------
> [Please describe your issue here]
>
> I was **tempted** to file this as a BUG (will explain)...
>
> >From the manpage: (perfunc on sprintf).
>
>        Unlike "printf", "sprintf" does not do what you probably mean
>        when you pass it an array as your first argument. The array is
>        given scalar context, and instead of using the 0th element of
>        the array as the format, Perl will use the count of elements in
>        the array as the format, which is ***almost never useful***.
>
>
> I would assert that this behavior goes against the "spirit of
> perl" to "always do the right thing".  To do something that is
> "almost never useful" can "almost never be the right thing".
>
>
> Is there some **REAL** good reason why sprintf should not behave/
> be compatible with printf?  I just wasted eh...maybe 10-15 minutes
> concocting a "printf" statement -- that I wanted to print to a
> variable, that would be passed the format and args in array,
> only to discover this *wart*.
>
> **Either that, or** have 'printf' be able to print to a variable! (which
> is a bit 'lame', considering that's the point of sprintf).
>
> Why would the implementation / behavior of sprintf be different than
> printf.   The whole point (I thought) was to be able to redirect output
> to a string instead of a file handle.
>
> If that's is not the point then a workaround, (actually, it would
> be a more generally purpose solution), would be to implement/allow:
>
>        open($handle, \$myvar, ">");
>
> then I could printf $handle.  Could even:
>
>        open($handle, \$myvar, "<>");
>        print $handle "hello world\n";
>        seek $handle 0,SEEK_SET;
>        while(<$handle>) {
>                print
>        }
> (out:)
>        hello world
>
> .. and get file-semantic behavior from a var...
>
> I actually like this 2nd idea, but it DOESN't mean the 'wart'
> on sprintf's implementation should remain.
>
> So *WAS* there some reason to make sprintf incompat w/printf
> in syntax-functionality?  Doesn't seem to make alot of sense
> and seems to be an unnecessary resriction.
>
> (I really was under the 'illusion/misunderstanding', that sprintf
> and printf were 'identical' except one took a file handle and the
> other sent output to a var...*doh!* (hits self over head?))...
>
>
> BTW -- would it be 'useful' for me to submit an RFE for my 'side
> comment above'?   I've thought about it's desirability before.
>
> ***Given***, the increases in available memory, being able to use a meg
> or more of 'memory' in a "var" as a "scratch file", doesn't seem at
> all like an unreasonable feature...
>
>
>
> [Please do not change anything below this line]
> -----------------------------------------------------------------
> ---
> Flags:
>    category=core
>    severity=wishlist
> ---
> This perlbug was built using Perl 5.12.3 - Fri May  6 13:31:41 UTC 2011
> It is being executed now by  Perl 5.12.3 - Fri May  6 13:26:30 UTC 2011.
>
> Site configuration information for perl 5.12.3:
>
> Configured by abuild at Fri May  6 13:26:30 UTC 2011.
>
> Summary of my perl5 (revision 5 version 12 subversion 3) configuration:
>
>  Platform:
>    osname=linux, osvers=2.6.36, archname=x86_64-linux-thread-multi
>    uname='linux build33 2.6.36 #1 smp 2011-02-21 10:34:10 +0100 x86_64
> x86_64 x86_64 gnulinux '
>    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr
> -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm
> -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -Wall -pipe
> -Accflags=-DPERL_USE_SAFE_PUTENV'
>    hint=recommended, useposix=true, d_sigaction=define
>    useithreads=define, usemultiplicity=define
>    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>    use64bitint=define, use64bitall=define, uselongdouble=undef
>    usemymalloc=n, bincompat5005=undef
>  Compiler:
>    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV
> -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64',
>    optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2
> -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall
> -pipe',
>    cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -DDEBUGGING
> -fno-strict-aliasing -pipe -fstack-protector'
>    ccversion='', gccversion='4.5.1 20101208 [gcc-4_5-branch revision
> 167585]', gccosandvers=''
>    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
>    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
>    alignbytes=8, prototype=define
>  Linker and Libraries:
>    ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
>    libpth=/lib64 /usr/lib64 /usr/local/lib64
>    libs=-lm -ldl -lcrypt -lpthread
>    perllibs=-lm -ldl -lcrypt -lpthread
>    libc=/lib64/libc-2.11.3.so, so=so, useshrplib=true, libperl=libperl.so
>    gnulibc_version='2.11.3'
>  Dynamic Linking:
>    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
> -Wl,-rpath,/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE'
>    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64
> -fstack-protector'
>
> Locally applied patches:
>
>
> ---
> @INC for perl 5.12.3:
>    /usr/lib/perl5/site_perl/5.12.3/x86_64-linux-thread-multi
>    /usr/lib/perl5/site_perl/5.12.3
>    /usr/lib/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi
>    /usr/lib/perl5/vendor_perl/5.12.3
>    /usr/lib/perl5/5.12.3/x86_64-linux-thread-multi
>    /usr/lib/perl5/5.12.3
>    .
>
> ---
> Environment for perl 5.12.3:
>    HOME=/home/law
>    LANG=en_US.UTF-8
>    LANGUAGE (unset)
>    LC_CTYPE=en_US.UTF-8
>    LD_LIBRARY_PATH (unset)
>    LOGDIR (unset)
>
>  PATH=.:/sbin:/usr/local/sbin:/opt/lsb/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin
>    PERL_BADLANG (unset)
>    SHELL=/bin/bash
>
>
Uh, you can already do all the stuff you request, y'know:

my @arr = ( "%s\n", "hullo" );
my $result = sprintf $arr[0], $arr[1..$#etc];
say $result;

Or if you think that's ugly, you can do this in blead:
my @arr = ( "%s\n", "hullo" );
my $result =&CORE::sprintf(@arr);
say $result;

Printing to a scalar has also been in core for a while:
open my $fh, ">", \my $scalar or die $!;
say { $fh } "hullo";
close($fh);
say $scalar;

I wouldn't call it a wart, any more than I'd call anything that uses
prototypes a wart. Admittedly it's counterintuitive at first, but expecting
sprintf @arr to work would mean that open @arr should also work, and so on;
That road leads to madness.

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