File constructor inconsistent behaviour

[Lukáš Lalinský]

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
>