Front page | perl.perl5.porters |
Postings from December 2011
[perl #103492] more documentation lies, plus The Unicode Bug *again*
Thread Previous
|
Thread Next
From:
Father Chrysostomos via RT
Date:
December 31, 2011 16:50
Subject:
[perl #103492] more documentation lies, plus The Unicode Bug *again*
Message ID:
rt-3.6.HEAD-14510-1325379043-279.103492-15-0@perl.org
On Wed Nov 16 04:44:12 2011, tom christiansen wrote:
> "Hugo van der Sanden via RT" <perlbug-followup@perl.org> wrote
> on Tue, 15 Nov 2011 23:56:44 PST:
>
> >Brian Fraser <fraserbn@gmail.com> wrote:
> >:Apparently this was introduced here
>
>:http://perl5.git.perl.org/perl.git/commit/fc36a67e8855d031b2a6921819d899eb1=
> >: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
<http://cpansearch.perl.org/src/COMSKIL/Comskil-JIRA-00.11329/lib/Comskil/JWand.pm>,
which uses it by mistake:
my $ilist = eval {
$self->{client_handle}->getIssuesFromJqlSearch($jql,$self->{':max_results'})
};
if ($@) {
carp sprintf("getIssuesFromJqlSearch('%s',%n):
%s",$jql,$self->{':max_results'},$@);
last;
}
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
arguments.
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
https://rt.perl.org:443/rt3/Ticket/Display.html?id=103492
Thread Previous
|
Thread Next