- Follow the best practices of https://reuse.software/ to ensure BSD-3 licence is correctly applied.
- Add a badge to README.md
- Note: remove arm build as the CI pipeline is broken for this architecture
To make it more clear to users and tooling that the project is a C++ project use the extension .hpp for pure C++ headers.
Add a new public header file charls.hpp. External C++ projects should this header file, C projects should still use charls.h.
The Azure CI Pipeline can analyze code coverage when running the unit tests. Enable this option. It provides an additional tab on the CI status report. On this tab a single code coverage number is displayed. The .coverage file can be downloaded and opened in Visual Studio to get more insights.
Only the debug DLL is code covered as it provided a good report. The release build has too many optimalizations to provide a report that is useful.
Note 1: The unit test DLL needs to link with the CharLS .obj files to make it possible to unit test low level methods. This means however the the unit test DLL needs to be code covered and not the actual CharLS DLL.
Note 2: the Cobertura format was also tested, but it didn't provide additional details (only more warnings and complexity)
Enable code coverage in CI pipeline
The release of C++17 has been 5 years ago. The supported period of C++14 has ended and the minimum required C++ version will be increased to C++17 for building the library and using it.
The destructor of std::ofstream will close the stream, but not report any failures (by design).
Call close to trigger an exception when the close fails.
static_cast for constant values can be replaced with uniform initialization, this allows
to reduce the number of static_casts.
Change the bin+intermediate to be sub-directories of build for MSBuild builds.
This makes it easier to clean.
- Use a span to manage the segment data
- Use a forward iterator
- Parse the SOS segment directly.
- Do a size check when segment size is known, then read without size checks.
- Don't use std::vector to read bytes.
Backport C++20 countl_zero
1) countl_zero can be used in peek_0_bits and is 2X faster.
Note: peek_0_bits is not on a hot path, overall gain is limited.
2) Apply updates for clang-tidy v13 (ships with VS 2022 17.1 Preview 2)
3) Increase upper range of supported CMake to 3.22
The latest MSVC compiler makes it possible to mark executable images CET compatible. Enable this opt-in option.
Note: CET is only enabled when the CPU, OS and the hosting process supports it.
When encoding images ensure that only the valid bits are used. For bit size 16 and 8 there is no change and memcpy will be used.
Encoding with masking is not measurable slower.
Setting explicit InlineFunctionExpansion for debug needs to be removed as it prevents debugging. For release mode it is also not needed as MaxSpeed will already enable it.
Mask high input bits during encoding (interleave_mode::sample)
Mask high input bits during encoding
- Control Flow Guard provides more security on the Windows platform.
- To use the add_link_options, the minimum required CMake version needs to be increased to v3.13
The .NET adapter has been moved to its own repository at https://github.com/team-charls/charls-native-dotnet
The .NET adapter in this repository was for .NET standard 2.0, which has been replaced by .net5.0
Having the .NET adapter in its own repository makes releasing easier and many uses case only require the "pure" C++ native library.
All C and C++ source code is encoded as utf-8 without a signature (bom). The GCC and clang compiler will read by default source code files in that format.
The MSVC compiler will look for a signature (bom), if non is found then the default system codepace encoding is used.
/utf-8 ensure that the correct source and executing encoding is used and that conversions are validated.
As no special characters are used in the source code, this is only a technical correction.
Enable clang-tidy for the MSBuild checked build configuration. The CharLSUnitTest project is excluded as clang-tidy is extreme slow for this project.
The warning clang-diagnostic-sign-conversion requires more planning before this warning can be global enabled.
The version number was defined in charls.rc, CMakeLists.txt and version.h. Refactor to make it possible to only have the version number in version.h
Additional:
- convert the .rc file encoding to utf8 (improved git compatibility)
- add an additional DLL build for VS2015
- Remove linker warnings for VS2015 DLL x64 build
Address feedback from the SonarCloud static analyzer, replace strcpy with a safe implementation. As no cross platform solution is available, introduce a #ifdef/#else based solution.
Also get rid of _CRT_SECURE_NO_WARNINGS by removing a not used function and using std::ifstream instead of fopen\fclose.
The latest MSVC compiler is more conformant and the warnings have been improved. Enable warnings that have been disabled in the past because there too many false positives.
The current C API prevents adding new features and the introduction of an object oriented C++ interface. Every change results directly in a ABI break. To prevent this a new C API is introduced that is easier to extend and to maintain. On top of this API are 2 C++ classes: jpeg_encoder and jpeg_decoder to encode and decode JPEG-LS files.
This commit comes also with the following changes:
- Updated .clang-format
- Switch to Visual Studio 2019 for the CI build pipeline
- Support for reading and writing SPIFF header
- Incomplete support for JFIF header has been removed
- Extended unit test coverage
<RunCodeAnalysis> cannot be defined globally, as it should not be enabled for .NET projects.
Disable C++ checker C26487 as it generates too many false warnings.
Add missing <string> include
Note: it is not possible to use .NET Core for this unit test project. Only 1 dotnet.exe can be in the path, and while both the x64 and x86 version can be installed, only 1 can be active. This makes it impossible to test both the x64 and the x86 build.
Other changes:
- Remove JpegLSBitmapDecoder (unsupported by .NET Core)
- Rename solution name from Win32 to x86 to ensure CI build works.
The modern way of CMake build script has changed. To make CharLS more package friendly, update the overall CMake structure to modern CMake.
For the moment target CMake 3.9 as the minimum, as this version is available on the Travis CI build system.
Visual Studio 2017 15.9 Preview 4 is required on the Windows platform, but the Visual Studio solution file and MSBuild projects is on that platform the supported way to build CharLS.
Modern practice is to move the interface header files to a include/<lib-name> folder. This prevents that header filenames conflict with other libraries. And it also allows client code to use #include <package-name\header-filename.h> constructions.
W4 is the recommended warning level by Microsoft. Wall however provides some more checking and is useful to detect additional problems. It requires however that some informational warnings are disabled.
