According to EA IFF 85:
Type IDs
A "type ID", "property name", "FORM type", or any other IFF identifier
is a 32-bit value: the concatenation of four ASCII characters in the
range R S (SP, hex 20) through R~S (hex 7E). Spaces (hex 20) should
not precede printing characters; trailing spaces are ok. Control characters
are forbidden.
Unfortunately, MSVC exports everything (not only public members) when
__declspec(dllexport) is set at the class level via TAGLIB_EXPORT, which
leads to many "needs to have dll-interface to be used by clients" 4251
warnings issued by MSVC, because the std::unique_ptr pimpls are
exported too. As it is not possible to "unexport" private members,
such a warning has to be explicitly suppressed for these cases or
all public and protected class member now have to be exported
for classes derived from a template (StringList, ByteVectorList,
PropertyMap).
- APE::Item::value(): use binaryData()
- APE::Item::toStringList(): use values()
- MPEG::ID3v2::Frame::Header::unsycronisation(): use unsynchronisation()
If an M4A file contains trailing garbage (e.g. an APE tag at the
end of the file), it was considered invalid since [e21640b].
It is important to make sure that atoms which affect modifications
written by TagLib are valid, otherwise the file might be damaged.
However, in cases where invalid atoms do not affect modifications
(which are only done inside the root level "moov" and "moof"
containers), they can be safely ignored.
This commit allows trailing garbage in M4A files as it is also
accepted in MP3, WAV and DSF files.
Many shadowFunction, some useStlAlgorithm, and others.
cppcheck --enable=all --inline-suppr \
--suppress=noExplicitConstructor --suppress=unusedFunction \
--suppress=missingIncludeSystem --project=compile_commands.json
When calling setAutoDelete() on the implicitly shared copy of a list,
also auto-deletion of the original container was modified because
it was not detached. On the other hand, detach() was called by some
methods getting an Iterator parameter, which can lead to modification
of other implicitly shared copies but not the object is was called on.
This happens when the method is called on a not-already-detached
container, which is normally not the case because the container is
detached when the iterator is taken (e.g. calling begin()).
In such methods detach() cannot be called, and the client must
make sure that the iterator is taken after making an implicit copy.
This will NOT work:
List<int> l1 = { 1 };
auto it = l1.begin();
List<int> l2 = l1;
l1.erase(it);
This will modify both l1 and l2. The second and the third lines
must be swapped so that l1.begin() will detach l1 from l2.
