Front page | perl.perl5.porters |
Postings from December 2011
<URL: https://rt.cpan.org/Ticket/Display.html?id=73623 > On Fri Dec 30 23:26:12 2011, ikegami@adaelis.com wrote: > On Fri, Dec 30, 2011 at 9:15 PM, Linda A Walsh via RT < > bug-Encode@rt.cpan.org> wrote: > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=73623 > > > How is that a correction?? > > > > I was correcting what *I* said. > > 1)...why would encode convert to BE on a LE machine? > > > What does Encode have to do with your machine? ---- That's where the test was run. Data is usually in the machines native format unless you are specifically trying to export it somewhere (like over the Net, then 'network byte order' is used). > > 2) since piconv states that is "designed to be a drop in replacement for > > iconv" and "iconv seems to assume LE", (maybe it only does so on LE > > machines?)... then I would assert there is a still a problem. > > > > Yes. Go ahead a file a bug if you want. --- The original test case showed using iconv 2 directions... for some reason the perlbug SW chopped that off .. anything after the uuencoded file I included, ws chopped off... that had a whole explanation and demonstration of the bug using the above data file (above in the original bug report that seems to have been corrupted by perl's bug system). The bug was the piconv didn't work as a drop in for iconv as I took a simple doc and converted to utf-8 and then back to utf-16, and original and the twice converted compared identical. I tried to do the same with piconv, but piconv failed at the first step. Why the original bug report was truncated at the data point, seems to be another bug in the perlbug reporting system. Perhaps it would be better to report that one as this one is still not fixed as the title perl';s conversion fails when iconv succeeds is still true. That's why I said 'closer', but not quite there.Thread Previous | Thread Next