RFR(xs): 8225225: stringStream internal buffer should always be zero terminated

David Holmes david.holmes at oracle.com
Wed Jun 5 08:08:30 UTC 2019


On 5/06/2019 5:43 pm, Thomas Stüfe wrote:
> Hi David,
> 
> 
> 
> On Wed, Jun 5, 2019 at 9:38 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     On 4/06/2019 6:06 pm, Thomas Stüfe wrote:
>      > Hi all,
>      >
>      > please review this small fix and the associated test:
>      >
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8225225
>      > Webrev:
>      >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8225225-stringstream-should-always-be-zero-terminated/webrev.00/webrev/
>      >
>      > This patch makes sure the internal buffer of stringStream is
>     always zero
>      > terminated.
> 
>     I don't see why a newly constructed empty stringstream needs to be
>     zero-terminated. We ensure zero termination if we write, and we ensure
>     we zero-terminate when we convert via as_string. If someone uses base()
>     to directly access our internal buffer (why do we allow that??) then
>     they need to be marginally careful when size() is 0.
> 
> 
> This is a preparation patch for 
> https://bugs.openjdk.java.net/browse/JDK-8224212 . I posted a separate 
> RFR for that one.
> 
> Calling stringStream::base() is a valid way to access the assembled 
> string and often more efficient than as_string(). Especially in cases 
> where the stringStream has been used to assemble a larger report.
> 
> That is why I want to guarantee that ::base() returns always a zero 
> terminated string, regardless the stream state.

Hmmm okay.

> 
>     But if you do make this change then surely here:
> 
>        370 char* stringStream::as_string() const {
>        371   char* copy = NEW_RESOURCE_ARRAY(char, buffer_pos + 1);
>        372   strncpy(copy, buffer, buffer_pos);
>        373   copy[buffer_pos] = 0;  // terminating null
> 
>     we don't need to do this as we must have copied across a terminating
>     NUL? (Actually doesn't that apply now, other than when size() == 0?)
> 
> 
> You are right. Also, a simple strcpy would be sufficient since the 
> receiving buffer is large enough.

I think code-checkers might still be more happy with the strncpy.

Thanks,
David

> Cheers, Thomas
> 
> 
>     Thanks,
>     David
> 
>      > It also extends existing gtests to assert this.
>      >
>      > In addition, gtests are expanded to test fixed sized stringStream
>     variants
>      > too, and to test for buffer overflow for both bufferedStream and
>      > stringStream (not strictly related to this fix but I was in the
>     area so..).
>      >
>      > Thanks, Thomas
>      >
> 


More information about the hotspot-runtime-dev mailing list