You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We observed this problem on boost 1.71, but it is also present in 1.81.
Problem description
On a system with 4-byte int and an INT_MAX of 2147483647, attempting to store more than that in a basic_vectorbuf causes problems due to converting a larger type (std::char_traits::off_type or std::vector::difference_type) to an int:
std::streambuf::pbump and std::streambuf::gbump both implicitly convert to int,
passing more than INT_MAX to these functions moves pptr/gptrbeforepbase/eback - access causes segmentation fault;
there are a couple of other type casts to int which would also produce negative offsets due to overflow.
How to reproduce
The problem is fully reproducible by
storing more than INT_MAX elements in a basic_vectorbuf, or
using reserve() to allocate more than INT_MAX elements, and then calling seekoff or tellp() once the write position has advanced past INT_MAX.
The text was updated successfully, but these errors were encountered:
We observed this problem on
boost
1.71, but it is also present in 1.81.Problem description
On a system with 4-byte
int
and anINT_MAX
of 2147483647, attempting to store more than that in abasic_vectorbuf
causes problems due to converting a larger type (std::char_traits::off_type
orstd::vector::difference_type
) to anint
:std::streambuf::pbump
andstd::streambuf::gbump
both implicitly convert toint
,INT_MAX
to these functions movespptr/gptr
beforepbase/eback
- access causes segmentation fault;int
which would also produce negative offsets due to overflow.How to reproduce
The problem is fully reproducible by
INT_MAX
elements in abasic_vectorbuf
, orreserve()
to allocate more thanINT_MAX
elements, and then callingseekoff
ortellp()
once the write position has advanced pastINT_MAX
.The text was updated successfully, but these errors were encountered: