Aristotle Pagaltzis wrote: > * Linda Walsh <perlbug-followup@perl.org> [2011-09-27 22:40]: > Is there some **REAL** good reason why sprintf should not behave/ be > compatible with printf? > > No. There isn’t. ---- I'm glad you agree, it's a bug in the design of the language. >> 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. ---- I did emphasize the trivial amount of time I wasted... i.e. it wasn't a huge deal...but I realized how ugly the problem was. Literally, I had a routine that just passed an optional error code and list, where the first arg could be a format or not, to a general error routine -- then I realized I really wanted to call DIE instead of sprintf and exit, and massage the string to interpret the error code as an '$ERRNO' in a string context.. The massaging part was doable, but to get a string w/formatting that didn't use printf it really seemed like I should be able to take the LIST comprised of either a simple string, or a format followed by it's args that was located in the rest of the @ARGS -- that I had been passing to printf in "printf STDERR, @ARGV" => "die sprintf @ARGV"; In C, those calls are much more parallel, with different names to indicate what optional args are at the beginning, but other than the otional args...they all take a uniform (same type) list of 'char * format, ...'. Since sprintf and printf both are documented to be implemented on top of the local [POSIX-compat] C library, then a difference in their invocation, from the documentation, would be an error. > There is no good reason. It just is. --- Usually those are things that need to be fixed. When I was told stuff like that as a child, it usually involved religious issues that I questioned and ultimate refused to accept. > > That’s gross. Please don’t do that. Think of the poor wretch who will > work on the code after you. --- That's, **usually**, me. When I do something that is less than str8 forward, I try to make sure it is well documented enough that I'll understand it in 'N' months, as in 'N' months, I'll remember nothing about why I did such -- have had it happen too many times NOT to document such. But it would have to be that it was algorithmically the right choice (more efficient, flexible), not just for the sake of doing it. > >> 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. Of course it is relevant. If something is needlessly broken and can be fixed, why would you just choose to live with it? If humans took that attitude as a whole, society would never change. > > 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. ---- As demonstrated by later example, trying to use it's existing behavior in any meaningful way fails, so there is an extremely low probability of any existing code breaking if such a change were to be made. There have been other changes in perl code where old features have been deprecated and changed that would have been FAR more likely to cause an incompatibility that were changed because those features were considered 'warts' or roadblocks to forward progress. There was no 'pity' for them. There was only change and 'deprecation' when needed. > >> So *WAS* there some reason to make sprintf incompat w/printf in >> syntax-functionality? > It’s just an accident of history. ---- That you agree it's a mistake makes moving forward a far easier task...otherwise, perl 5.12.0 would be bound to the same feature set as 4.0, which fortunately, is not the case. LindaThread Previous | Thread Next