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

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

Thread Next
Linda Walsh
September 27, 2011 13:36
[perl #100190] RFE: fix sprintf to be consistent with printf and be useful!
Message ID:
# New Ticket Created by  Linda Walsh 
# Please include the string:  [perl #100190]
# in the subject line of all future correspondence about this issue. 
# <URL: >

This is a bug report for perl from,
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>) {
	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]
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:
    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
    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/, so=so, useshrplib=true,
  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:

Environment for perl 5.12.3:
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PERL_BADLANG (unset)

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