[Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

[maechler at stat.math.ethz.ch]

>>>>> "vQ" == Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no>
>>>>>     on Thu, 23 Apr 2009 15:00:29 +0200 writes:

    vQ> Martin Maechler wrote:
    >>>>>>> "vQ" == Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no>
    >>>>>>> on Thu, 23 Apr 2009 11:49:54 +0200 writes:


[......................]
[......................]

    >> >> BTW,  
    >> >> 1) sprintf("%n %g", 1,1)   also seg.faults
    >> >> 
    >> 
    vQ> as do
    >> 
    vQ> sprintf('%n%g', 1, 1)
    vQ> sprintf('%n%')
    >> 
    vQ> etc., while
    >> 
    vQ> sprintf('%q%g', 1, 1)
    vQ> sprintf('%q%')
    >> 
    vQ> work just fine.  strange, because per ?sprintf 'n' is not recognized as
    vQ> a format specifier, so the output from the first two above should be as
    vQ> from the last two above, respectively.  (and likewise in the %S case,
    vQ> discussed and bug-reported earlier.)
    >> 
    >> I have now fixed these bugs at least;
    >> 

    vQ> great, i'm going to torture the fix soon ;)

there will be another one, still today, fixing the

      sprintf("%s", tryCatch(stop(), error=identity))

bug {which actually *is* a subtle, too}

    >> the more subtle  "%<too_large_n>d" ones are different, and
    >> as I said, I'm convinced that a nice & clean fix for those will
    >> start using snprintf().
    >> 
    >> >> 2) Did you have a true use case where  the  8192  limit was an
    >> >> undesirable limit?
    >> 
    vQ> how does it matter?  
    >> 
    >> well, we could increase it, if it did matter.
    >> {{ you *could* have been more polite here, no?
    >> 

    vQ> i don't see how i could be more polite here, i had absolutely no
    vQ> intention to be impolite and didn't think i were. 

    vQ> i gave a serious answer by means of a serious question.  increasing an
    vQ> arbitrary, poorly documented limit of obscure effect is hardly any
    vQ> solution.  suggesting that a bug is not a bug because some limit is not
    vQ> likely to be exceeded in practice is not a particularly good idea.

But that's exactly what I did  NOT  suggest!!

It was a serious question, *related* to your bug report, but
*NOT* really on the bug report proper.
[It *was* under the "heading" of 'BTW' which I assumed you knew
 to interpret]
I was seriously asking, if BTW, the limit which is there was
possibly to be increased or not...


    >> it *was* after all a serious question that I asked! }}
    >> 
    vQ> if you set a limit, be sure to consistently enforce
    vQ> it and warn the user on attempts to exceed it.  or write clearly in the
    vQ> docs that such attempts will cause the output to be silently truncated. 
    >> 
    >> Sure, I'm not at all disagreeing on that, and if you read this into my
    >> posting, you misunderstand.
    >> 

    vQ> no, i didn't read that into your posting, i'm just referring to the
    vQ> state of the 'art' in r.

[not so funny...  yet another "very polite" assumption.]

    vQ> cheers,
    vQ> vQ