error: writing 32 bytes into a region of size 28 [-Werror=stringop-overflow=]

[PhilipDeegan]

yaml-cpp/src/fptostring.cpp

Line 188 in 1870e4b

*(output_ptr++) = *(digits_iter++);

src/fptostring.cpp: In function ‘std::string YAML::detail::fp_formatting::FpToString(T, int) [with T = float]’:
src/fptostring.cpp:188:25: error: writing 32 bytes into a region of size 28 [-Werror=stringop-overflow=]
  188 |         *(output_ptr++) = *(digits_iter++);
      |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
In file included from src/fptostring.cpp:4:
/usr/include/c++/15/array:117:55: note: at offset [0, 27] into destination object ‘std::array<char, 28>::_M_elems’ of size 28
  117 |       typename __array_traits<_Tp, _Nm>::_Type        _M_elems;
      |                                                       ^~~~~~~~
src/fptostring.cpp:134:24: note: at offset [1, 28] into destination object ‘output_buffer’ of size 28
  134 |   std::array<char, 28> output_buffer;
      |                        ^~~~~~~~~~~~~
src/fptostring.cpp: In function ‘std::string YAML::detail::fp_formatting::FpToString(T, int) [with T = double]’:
src/fptostring.cpp:188:25: error: writing 32 bytes into a region of size 28 [-Werror=stringop-overflow=]
  188 |         *(output_ptr++) = *(digits_iter++);
      |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
/usr/include/c++/15/array:117:55: note: at offset [0, 27] into destination object ‘std::array<char, 28>::_M_elems’ of size 28
  117 |       typename __array_traits<_Tp, _Nm>::_Type        _M_elems;
      |                                                       ^~~~~~~~
src/fptostring.cpp:134:24: note: at offset [1, 28] into destination object ‘output_buffer’ of size 28
  134 |   std::array<char, 28> output_buffer;

[PhilipDeegan]

╰─$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,cobol,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugzilla.redhat.com/ --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-15.2.1-build/gcc-15.2.1-20260123/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 --disable-libssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.2.1 20260123 (Red Hat 15.2.1-7) (GCC)

[SGSSGene]

@PhilipDeegan thank you for the report an the PR!

I am trying to recreate the warning/error. I am assuming you are using the current master branch.
Could you tell me the exact gcc call with all the flags? (ups, just seeing it is -Werror=stringop-overflow)

[PhilipDeegan]

Hi Gene

I am using master yes, but, master HEAD seems a bit weird in terms of dates?

commit 1870e4be3a409cc87282d65466b7ea572af93fc7 (HEAD -> master, origin/master, origin/HEAD)
Author: mosfet80 <10235105+mosfet80@users.noreply.github.com>
Date:   Fri Sep 19 09:42:35 2025 +0200

    Update CXX requirement
    
    googletest 1.13 requires at least C++14
    
    log: fix tests using c++ version from googletest

commit 0b7ce1d47cb6a67d40012d8ecf47882953aaf282
Author: Vadim D <36827317+vvd170501@users.noreply.github.com>
Date:   Mon Dec 30 22:47:32 2024 +0300

    Cloning a node preserves marks
    
    \#log: behaviour change: cloning a node preserves markings

[SGSSGene]

I am using master yes, but, master HEAD seems a bit weird in terms of dates?

This happens because of the way we merge PRs. The commit has been made in September but was just recently merged.

The report by gcc seems to be a false positive.

for (int i{0}; i < std::min(before_decimal_digits, digits_ct); ++i) {
   *(output_ptr++) = *(digits_iter++);
}

the value of digits_ct is 20 or lower meaning the for loop will not be executed more than 20 times.
Since output_ptr has only been increased by at most one before this loop, this will only write into the array first 21 indices. Never touching any values above 21.
(This of course does not mean I haven't overlooked something and my explanation is wrong).

I tried to reproduce the warning you get. I neither get it with gcc 15.2.1 from the arch which is slightly newer :gcc version 15.2.1 20260209 (GCC)
Nor with the gcc I can get through dockers redhat/ubi10:latest image which is gcc version 15.1.1 20250521 (Red Hat 15.1.1-2) (GCC)

I would rather not blindly increase the value of 28 to 32.
Either their is a bug in yaml-cpp, than we need to understand and fix it.
Or there is a bug in gcc which in that case could just be ignored, since by default it is just a warning.

Any idea on reproducing it on a different machine would be appriciated.

[PhilipDeegan]

it only seems to appear if the command includes -std=c++20

which is to say, if my options override cmake defaults

[SGSSGene]

it only seems to appear if the command includes -std=c++20

which is to say, if my options override cmake defaults

Assuming you are using cmake + make, could you run make VERBOSE=1 and pick out the call to c++ for fptostring.cpp
It should say something like:

[ 21%] Building CXX object CMakeFiles/yaml-cpp.dir/src/fptostring.cpp.o                                                                                                                                                                                                                                                        
/usr/lib/ccache/bin/c++ -DYAML_CPP_STATIC_DEFINE -I/home/gene/Coding/yaml-cpp/include -I/home/gene/Coding/yaml-cpp/src -Wall -Wextra -Wpedantic -Werror=stringop-overflow=2 -O3 -march=znver5 -O3 -DNDEBUG -fPIC -Wall -Wextra -Wshadow -Weffc++ -Wno-long-long -pedantic -pedantic-errors -MD -MT CMakeFiles/yaml-cpp.dir/src/
fptostring.cpp.o -MF CMakeFiles/yaml-cpp.dir/src/fptostring.cpp.o.d -o CMakeFiles/yaml-cpp.dir/src/fptostring.cpp.o -c /home/gene/Coding/yaml-cpp/src/fptostring.cpp   

This will show me all the set flags and hopefully recreate the warning/error message you are getting.

[PhilipDeegan]

g++ -std=c++20 -Iinclude -O3 -funroll-loops -march=native -mtune=native -Wall -Wextra -pedantic -Werror -o fptostring.cpp.o -c src/fptostring.cpp

if you run this from the project root you should see it
it only also appears with optimizations on

clang doesn't say anything so it might be a false positive

[SGSSGene]

g++ -std=c++20 -Iinclude -O3 -funroll-loops -march=native -mtune=native -Wall -Wextra -pedantic -Werror -o fptostring.cpp.o -c src/fptostring.cpp

Yes! thank you, with -march=znver5 I get can reproduce it and get the same error. I will look into it!

[SGSSGene]

I am now convinced that this is a false positive. Adding the following lines at the end of ConvertToChars will remove the error.

...
  if (digits_ct > end-begin) {
    throw std::logic_error("This should be impossible to happen. 2^64 has a maximum of 20 digits so this should never be thrown");
  }
  return digits_ct
}

This will never trigger but remove the error.

Also remove the following removes makes the warning also disappear.

  if (r.is_negative) {
    *(output_ptr++) = '-';
  }

Similarly removing the line ret_value.resize(ret_value.size() + overflow_zeros, '0'); also makes the warning disappear.

I think we still need someway to deal with false positive. My suggestion would be adding a cmake option that turns the strict flags off, see PR #1430 . I am assuming false positive will happen from time to time.

What do you think?

[PhilipDeegan]

I'm not sure you can ever truely avoid false positives as they seem to appear and disappear across compiler versions