Merge branch 'release'
Release 3.2.8
anyway applied to git/release branch let see how this goes. Thanks !
@taylorho please use my github/malaterre GDCM mirror next time. I do not use this sf.net UI a lot
Merge branch 'release'
feat: 12-bit allocation support
GDCM_BUILD_NETWORK support for wrappers and application
Introducing GDCM_BUILD_NETWORK CMake option (default: ON)
Merge branch 'release'
Don't abort the host on a failed decode: translate C++ exceptions in the Python bindings
Merge branch 'release'
CMake issue with libexpat fixed
Merge branch 'release'
BUG: Fix multi-fragment JPEG suspension in JPEGTurboCodec
Merge branch 'release'
UIH/VFRAME is actually never inverted
Fix typo
Add sentinels VFRAME vs MOSAIC
@malat can you please take a look here? I synced the work with the most recent changes, so there are no conflicts.
Default implied special members of DataSet and Item
Merge branch 'release'
Compatibility with CMake multi-config generators
Merge branch 'release'
Add more UIH private attributes
Add UIH private attributes
System::GetHostName unused
https://github.com/malaterre/GDCM/pull/218
There's another section catering legacy CMake just below: #----------------------------------------------------------------------------- +#[[ # Compatibility with older usage of EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH. # This should be removed in the future. if(EXECUTABLE_OUTPUT_PATH) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${EXECUTABLE_OUTPUT_PATH}) message(WARNING "EXECUTABLE_OUTPUT_PATH is deprecated. Use CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.") endif() if(LIBRARY_OUTPUT_PATH) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY...
CMake legacy compatibility issue with unconditional setting of -NDEBUG
Merge branch 'release'
Release 3.2.7
Add UIH/PET dict
Merge branch 'release'
Add new UIH attributes
Relax tolerance
Add new UIH attribute
Merge branch 'release'
Add extra checks in gdcmtar
Rewwork UIH / GRID implementation
Start splitting UIH at gdcmtar level
Add SplitGrid to handle UIH
Merge branch 'release'
ENH: Improve robustness of JPEGTurbo encoding tests
BUG: Fix segfaults and lossless YBR encoding in JPEGTurbo backend
ENH: Add encoding tests for JPEGTurboCodec
ENH: Improve libjpeg-turbo version detection in CMake
ENH: Add libjpeg-turbo backend for GDCM JPEG codec
Merge branch 'release'
Only do the final doxygen run with GDCM_DOCUMENTATION=ON
Minimal UIH dict
Hi this was fixed in https://github.com/malaterre/GDCM/releases/tag/v3.2.3 With this fix https://github.com/malaterre/GDCM/pull/204
Hi, it was fixed in https://github.com/malaterre/GDCM/releases/tag/v3.2.3 https://github.com/malaterre/GDCM/pull/202
Hi, This was fixed in 3.2.3 - https://github.com/malaterre/GDCM/releases/tag/v3.2.3 https://github.com/malaterre/GDCM/pull/203
Hello! Sorry for bother you, do you have any updates here? Thanks
Hello! Sorry for bother you, do you have any updates here? Thanks
Hello! Sorry for bother you, do you have any updates here? Thanks
With this new branch and UBSan + libc++ hardening enabled, I don't see it at the current release. Used command line: rm -rf _build/; env CFLAGS="-std=c17" CC=clang CXX=clang++ cmake -S . -B _build -G "Ninja Multi-Config" -DCMAKE_INSTALL_PREFIX=_output -DGDCM_BUILD_APPLICATIONS=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_CXX_COMPILER_LAUNCHER=sccache -DCMAKE_C_COMPILER_LAUNCHER=sccache -DGDCM_USE_SYSTEM_ZLIB=ON -DGDCM_USE_SYSTEM_EXPAT=ON -DGDCM_LINK_LIBCXX=ON -DGDCM_HARDENING=ON...
Do you happen to know which Clang version and which libc++ version you used? Would also be useful to know if you used any libc++ hardening options. The error message suggests it a bit ...
Merged and thus fixed.
Merged as https://github.com/malaterre/GDCM/pull/210 and thus fixed.
This has been merged and is now fixed.
Hello! I'm from Debian LTS team. I'd like to know if you have news about this fix? Thanks
Hello! I'm from Debian LTS team. I'd like to know if you have news about this fix? Thanks
Hello! I'm from Debian LTS team. I'd like to know if you have news about this fix? Thanks
but maybe we should look into reading https://dicom.nema.org/medical/dicom/current/source/docbook/part03/part03.xml instead but that is probably more work than getting the old method to work.
Merge branch 'release'
Release 3.2.6
Add support for odd dimensions overlay
Merge branch 'release'
Updating IOD and Module List
Restore default initializer for RLEHeader::Offset[15]
Merge branch 'release'
Fix compilation on VS 2012/appveyor
Merge branch 'release'
This integrates zlib 1.3.2 as gdcmzlib
Merge branch 'release'
This addresses a missing define to make posix_memalign() and strnlen() available
Merge branch 'release'
This changes the inclusion of "zlib/zlib.h" to "gdcm_zlib.h"
Merge branch 'release'
The copyright should only be appended for vendored dependencies
Merge branch 'release'
If a copyright file does not exist, issue a warning instead of failing
Merge branch 'release'
Add test for OOB read in Overlay::GrabOverlayFromPixelData (CVE-2025-52582)
Fix OOB read in Overlay::GrabOverlayFromPixelData (CVE-2025-52582)
Merge branch 'release'
Fix CVE-2026-3650: reject Value Length exceeding stream size
Reading the patch, seems to be related to the CVE but, commit message didn't confirm it.
This issue appears to have been addressed in commit f0e359c87947326c7fb2f7b91ecbe351e9d8c683
This appears to have been addredded in commit: 0393310f8bb27c3bec8b67c6bfb18f71f6a15bb8
Hi! sorry for bother you. Do you have a plan to fix these CVE-*? Thanks
Several warnings -Wnontrivial-memcall with Clang 22
https://github.com/malaterre/GDCM/pull/208
https://github.com/malaterre/GDCM/pull/209
FYI zlib 1.3.2 got released in February 2026
I think Applications/Cxx/deflate.cxx should include gdcm_zlib.h rather than zlib/zlib.h
The FIPS-enabled trait usually means that the system (or libraries installed on it) has been placed into this mode. So this is in all likelihood some DSO reporting it (you already gave a suspect). However, I would assume that instead this comes from libcrypto itself (or similar). How do I come to this conclusion? There is no fips.c in this repo! Check yourself with find -type f -name fips.c. I suppose you trust the suspected gdcmswig.so file. If you do, run ldd /path/to/gdcmswig.so. If you don't,...
The FIPS-enabled trait usually means that the system (or libraries installed on it) has been placed into this mode. So this is in all likelihood some DSO reporting it (you already gave a suspect). However, I would assume that instead this comes from libcrypto itself (or similar). How do I come to this conclusion? There is no fips.c in this repo! Check yourself with find -type f -name fips.c. I suppose you trust the suspected gdcmswig.so file. If you do, run ldd /path/to/gdcmswig.so. If you don't,...
I forgot to mention the command line I use: preparational cleaning: rm -rf -- _build _output CMake generator step: env CFLAGS="-std=c17" CC=clang CXX=clang++ cmake -S . -B _build -DCMAKE_INSTALL_PREFIX=_output -DBUILD_SHARED_LIBS=ON -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_CXX_COMPILER_LAUNCHER=sccache -DCMAKE_C_COMPILER_LAUNCHER=sccache -DGDCM_USE_SYSTEM_ZLIB=ON -DGDCM_USE_SYSTEM_EXPAT=ON Actual build: cmake --build _build --config Release As one long copypasta line: rm -rf -- _build _output; env CFLAGS="-std=c17"...
