File constructor inconsistent behaviour

[Ibrahim Sha'ath]

Lukáš, thanks so much for the fix. I didn't expect it to be a TagLib bug =)

Ibrahim

2012/2/2 Lukáš Lalinský <lalinsky at gmail.com>

> This is not a TagLib bug, but a problem in your program. The result of
> QFile::encodeName is a QByteVector, but you are not storing it
> anywhere in the original form, you are just casting it to const char *
> and then forgetting the QByteVector, which is immediately destroyed.
> You are just lucky that it sometimes works, because the filePathCh
> points to unallocated memory.
>
> Lukas
>
> On Wed, Feb 1, 2012 at 7:46 PM, Ibrahim Sha'ath <ibrahimshaath at gmail.com>
> wrote:
> > Hi,
> >
> > In reading some mp3 files (in particular one with Japanese characters in
> the
> > filename), the following (Qt) code returns inconsistent results.
> >
> > (filePath is a QString passed by const ref, f is a Taglib::File*)
> >
> > QString fileExt = filePath.right(filePath.length() -
> > filePath.lastIndexOf(".") - 1).toLower();
> >
> > const char* filePathCh = QFile::encodeName(filePath);
> >
> > f = NULL;
> >
> > if(fileExt == "mp3"){
> >
> >   std::cerr << filePathCh << std::endl;
> >
> >   f = new TagLib::MPEG::File(filePathCh,false);
> >
> >   std::cerr << filePathCh << std::endl;
> >
> > }
> >
> >
> > Sometimes, when passed the path of a file, this code works fine,
> returning a
> > valid File object whose tags I can read and write; in these cases the two
> > prints to cerr are correct (showing the whole file path) and
> > identical. Other times, f is returned invalid, and while the first print
> to
> > cerr is correct, the second is either blank or incomplete (usually with
> the
> > beginning truncated). I cannot determine what causes the divergent
> > behaviour.
> >
> > This is all using TagLib 1.7 and Qt 4.7.4, on Mac OS 10.7.2. Does anyone
> > have any idea what might be causing this, or have you seen anything
> similar?
> > Any help appreciated.
> >
> > Best regards
> > Ibrahim
> >
> >
> > _______________________________________________
> > taglib-devel mailing list
> > taglib-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/taglib-devel
> >
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20120202/b26f55c4/attachment.html>