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

[perl #103492] more documentation lies, plus The Unicode Bug *again*

Thread Previous | Thread Next
Father Chrysostomos via RT
December 31, 2011 16:50
[perl #103492] more documentation lies, plus The Unicode Bug *again*
Message ID:
On Wed Nov 16 04:44:12 2011, tom christiansen wrote:
> "Hugo van der Sanden via RT" <> wrote
>    on Tue, 15 Nov 2011 23:56:44 PST:
> >Brian Fraser <> wrote:
> >:Apparently this was introduced here
> >:49eee2d
> >:So there's also a chance that Hugo van der Sanden is the true
> culprit! (The
> >:plot thickens)
> >There was a bunch of rewriting of sprintf around that time, initially
> >motivated by a security issue.
> >If I remember right, the problem started at the point the original
> code
> >decided "this is too hard for me to format myself, let me hand it to
> >the C library instead". The intent of the rewrite was to stop
> attempting
> >to use the C library sprintf.
> >I don't remember who added it, but as far as I know %n was added
> because
> >C library versions of sprintf had it. They still do - right now on
> this
> >Ubuntu box, `man 3 sprintf` gives:
> >   The conversion specifier
> >[...]
> >     n  The number of characters written so far is stored into the
> inte-
> >        ger indicated by the int * (or variant)  pointer  argument.
> No
> >        argument is converted.
> >I do not think it was ever expected to be particularly useful for
> perl code,
> >but the functionality is also directly accessible to C/XS code, for
> which %n
> >might have greater utility.
> >Quite what it should do in a modern perl I have no idea: I'm not
> entirely
> >sure even when it is useful from C, but I suspect it is more to do
> with
> >"is this buffer big enough" than anything else, in which case "number
> of
> >bytes" seems the more useful thing for it to record. For perl code I
> find
> >it difficult to imagine any uncontrived use bar obfuscation.
> Thank you, Hugo, for taking the time to fill us in with the history.

I did a naïve CPAN grep for /printf.*%n/.  The only code using this that
I found was
which uses it by mistake:

            my $ilist = eval { 

            if ($@) {
                carp sprintf("getIssuesFromJqlSearch('%s',%n):

At first glance (just looking at the sprintf line), I thought it was for
indenting more debugging output to follow, which would make sense.

So, by accident, I’ve come up with a use case.

Allowing the bytes to leak through to the Perl level is certainly a bug.
 There is no C code using this (afaict), and it wouldn’t be particularly
helpful to know the buffer size, anyway, as it could change during the
*same* sprintf operation if Unicode characters are encountered in later

So I would suggest we just fix this to work with characters.  It looks
like something that was simply missed during the Unicode overhaul.


Father Chrysostomos

via perlbug:  queue: perl5 status: open

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