On Mon, Sep 09, 2013 at 01:30:34AM -0400, Father Chrysostomos via RT <bug-Glib@rt.cpan.org> wrote:
Show quoted text> I wasn’t aware of any opinion that SvPVutf8 wasn’t broken as originally implemented.
AS often, when I reported it, I was told that this isn't considered a bug,
but instead the usage of SvPVutf8 would be in error. I had to implement
workarounds in quite a few places.
Show quoted text> That was long before I had anything to do with perl development. I’m
> afraid it’s too late to do anything about that now, specially since
> the majority of XS modules have updated to do things the new way (or
> were written after the new way became The Way).
Well, 99% of all statistics are made up on the spot, and this smells like
one. First of all, I doubt that this is even remotely true, and second,
all these new modules would unlikely to be broken, because very few
modules use SvPV and later check the utf-8 flag, and third, new modules
will suffer from the same bugs - each time xs modules use "char *" or
equivalent they are almost certain to be buggy, and a greta number of new
xs modules does exactly do that.
The problem is clearly ongoing, and not fixed as you naively assume.
Show quoted text> It was actually 5.10’s utter brokenness that led me to start
> contributing to perl, since the hundreds of bugs introduced in it
> didn’t seem to be getting addressed.
I thank you for it.
Show quoted text> > > > SvPV will return a valid utf-8 string because it contains only
> > > > ascii
> > > > characters).
> > >
> > > Not true, as a reference could stringify to "\xFF" it if thas
> > > overloading.
> >
> > Well, according to your patch description, the patch is susceptible to
> > that problem too as it uses the same logic: "As of commit fe46cbda82
> > SvPVutf8 no longer tries to coerce its argument if it is not already a
> > string.", so you are contradicting yourself here somewhere.
>
> I meant that your workaround described above, if you want to apply it in 5.14 and before, would be incorrect if it used SvPV for references, as SvPV(ref) can return bytes sequences that are not valid UTF-8.
That obviously wouldn't be a problem, as SvPV would only be used in the
non-string case.
Show quoted text> For 5.14, you would have to use SvPV, check the utf8 flag, and then convert the buffer if the utf8 flag was off.
... or use any number of other correct ways that might or might not be
faster, smaller, or worse.
Show quoted text> > Anyway, either there is a later patch that actually fixes it, or the
> > algorithm as outlined by me is actually correct, or both the algorithm
> > and
> > perl are buggy - but something must give.
>
> I don’t quite understand. I think it is because you misunderstood me. I think I wasn’t clear enough at first.
No, the point was that your own patch used basically the same algorithm,
but for some reason you either applied a dual standard (when you describe
the algorithm it's ok, when others do it's "not true"), or, more
importantly(!) at the time you wrote the patch you weren't aware of that
issue and the patch was wrong.
I felt it was my duty to point this out to you, as the latter case would
have meant that the problem you attributed to my description of the
algorithm would also be in yours, and thus, still in perl.
I'm glad to hear that it was just you being more picky about my words than
your own, so the result seems sane.
In any case, this discussion is too drawn out and off-topic for
rt.cpan.org, as it's unrelated to the problem at hand, and since
rt.cpan.org has this idiotic behaviour of hiding e-mail addresses (and
thus making it hard to contatc people directly), I won't spam it more
here.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_
http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
