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

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

Thread Previous | Thread Next
Aristotle Pagaltzis
September 29, 2011 03:48
Re: [perl #100190] RFE: fix sprintf to be consistent with printfand be useful!
Message ID:
* Linda Walsh <> [2011-09-27 22:40]:
> 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?

No. There isn’t.

> 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*.

Sorry for the time you wasted.

> **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.

There is no good reason. It just is.

> 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

That’s gross. Please don’t do that. Think of the poor wretch who will
work on the code after you.

> but it DOESN't mean the 'wart' on sprintf's implementation should
> remain.

Neither does it mean the wart should change. It’s not relevant.

If the behaviour of sprintf were to change, then a lot more people than
you would have a lot more than 15 of their minutes wasted; so more’s the
pity that it has to stay.

> 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.

It’s just an accident of history.

> (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?))...

Welcome to the wonderful world of software, full of annoying surprises
like that. Software sucks.

> 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...

It’s not relevant.

Aristotle Pagaltzis // <>

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