The pointer to a newline could not advance enough, when the line ended with \r\n. The resulting buffer was correct, as the buffer range went from <start> until \r, but that the pointer increased by just 1 could lead to the problem that the next pointer points at \n, which is still part of the newline and therefore, "getNextBlock" got 1 byte too much.
Refs Issue #4871
Several places in the code call `std::vector<aiVector3D>.emplace_back(0, 0, 0)`. The constructor of `aiVector3D` actually expects arguments of the type `ai_real`, (alias of `float` if compiling without `ASSIMP_DOUBLE_PRECISION`) but the literal `0` is of type `int`.
`emplace_back()` does support promotion, but `int` to `float` is a potentially lossy conversion. tl;dr: On warning level 4, MSVC spits out a very deeply nested `warning C4244: 'argument': conversion from '_Ty' to 'TReal', possible loss of data with _Ty=int and TReal=ai_real`.
This commit does not add or remove c’tors or d’tors, so it is *not* ABI-breaking.
If a c’tor/d’tor does nothing else than the default behavior, this commit replaces it with “= default”.
If an initializer list entry does nothing else than the default behavior, this commit removes it. First and foremost, remove default c’tor calls of base classes (always called by the compiler if no other base c’tor is explicitly called) and c’tor calls of members with complex types (e.g. “std::vector”).
In a few instances, user-defined copy c’tors / move c’tors / assignment operators / move assignment operators were replaced with “= default”, too. I only did this if I had a clear understanding of what’s going on.
This post process step introduced new attributes into `aiSkeletonBone`. Said attributes are only defined with the process enabled, i.e. when the `ASSIMP_BUILD_NO_ARMATUREPOPULATE_PROCESS` macro has not been defined.
Some code, however, accessed the variables unconditionally, leading to build failures if `ASSIMP_BUILD_NO_ARMATUREPOPULATE_PROCESS` was defined.
This commit adds the missing checks.
`M3DWrapper.h` is designed to omit the definition of `class M3DWrapper` if neither M3D import nor M3D export are compiled.
608bccd9cf touched the corresponding preprocessor checks and introduced a bug:
```
#ifndef ASSIMP_BUILD_NO_M3D_IMPORTER
#if !(ASSIMP_BUILD_NO_EXPORT || ASSIMP_BUILD_NO_M3D_EXPORTER)
class M3DWrapper {
```
When compiling
- with M3D import enabled,
- but with either export generally disabled or M3D export disabled specifically,
These checks evaluate to the wrong result and skip the definition, leading to a build failure in dependent code.
```
#if 1 // import enabled
#if !(1 || 1) // export disabled and M3D export disabled
```
This commit fixes the check to compile the definition if neither import is disabled.
It is an ODR violation to use a template specialization for which an
explicit specialization is defined somewhere whose declaration is not
visible at the point of use.
Found via clang's -Wundefined-func-template warning.
Kim Kulling
Matthias Möller
Robert Reif
Turo Lamminen
PencilAmazing
krishty
Krishty
shimaowo
Martin Mory
Martin Mory
Andy Maloney
sashashura
Umesh Rajesh Ramchandani
Kim Kulling
Thomas Köppe