the UTF-8 rendering and the UTF16-LE rendering to the same string, which was, well,
ungood.
(Sorry Dan, that's bad news for those files -- but this bug was only introduced 4
days ago, so it just hadn't been caught yet.)
BUG:109604
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@438731 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Specifically make sure that we don't actually allocate a buffer for a read that
extends beyond the end of the file.
BUG:101401
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@438035 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
that takes a maximum number of values. This should probably be used more widely in
places where the max is known ahead of time for this to be a more useful fix than nailing
just this special case. Anyway, fixes the bug.
BUG:103622
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@438030 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
This is generally much better thought out than the current method of creating
FileRefs using the native mime system and also allows for extension to additional
file formats.
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@437382 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
at the end of the list. Thanks to Gunnar Roth for catching this one.
BUG:96926
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@378404 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
the appropriate seek location. I'm pretty sure that this is what was causing
Ogg length information to not work on x86_64. Can you confirm Hamish?
BUG:86806
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@358653 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
to an integer before trying to convert it and (b) make sure that there's data
in an APE::Item before trying to parse it.
BUG:92028
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@358637 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Bumb version to have something to check for in JuK and kfile_mpc
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@330294 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
bit of feedback on whether or not the safe operation worked.
CCMAIL:83882@bugs.kde.org
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@323165 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
not include the trailing null characters. (This was introduced after the
last release.)
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@309070 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
to figure things out. This also allows the number conversion to be
templatized.
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@306699 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
so this didn't update the internal size of the std::vector...
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@302668 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Basically they fall into the categories:
- Don't convert things before you need to
- When you do, use more effecient copy constructors / assignment operators
(i.e. when copying prefer memcpy to a for loop and when that's not possible
use an iterator instead of operator[])
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@301896 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
methods. Here this improves tag reading speed by about 50%.
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@293774 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
statement, so both the UTF16 and the UTF16BE versions were being executed.
CCMAIL:Ilya Konstantinov <future@shiny.co.il>
git-svn-id: svn://anonsvn.kde.org/home/kde/trunk/kdesupport/taglib@290210 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
