Bug 64211

Summary:

stringbuf::underflow causes an infinite loop

Product:

[Retired] Red Hat Linux

Reporter:

Pavel Tsekov <ptsekov>

Component:

libstdc++

Assignee:

Jakub Jelinek <jakub>

Status:

CLOSED NEXTRELEASE

QA Contact:

Severity:

medium

Docs Contact:

Priority:

medium

Version:

7.2

CC:

ptsekov

Target Milestone:

---

Target Release:

---

Hardware:

i686

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2004-10-05 16:34:21 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
The simple patch I've used to solve the problem	none

Description Pavel Tsekov 2002-04-29 12:13:04 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
The following sample compiled with the libstdc++ coming with gcc 2.96-98 
results in an infinite loop:

char buf[2048];
stringstream s;
s.write (buf, 2048);
s.seekg (0, ios::beg);
s.read (buf, 2048);

The reason for this is that the get/put pointers are not set in the default 
constructor of the stringbuf class.

To fix this one needs to set the get/put pointers as it is done in the other 
stringbuf constructor - the one acception string.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
See the description.

Actual Results:  Infinite loop.

Expected Results:  Data should be read in the buffer.

Additional info:

Comment 1 Pavel Tsekov 2002-05-01 11:11:13 UTC

Created attachment 56024 [details]
The simple patch I've used to solve the problem

Comment 2 Pavel Tsekov 2002-05-01 20:22:34 UTC

I realize the 'Short Summary' is somewhat incorrect - a more approapriate one 
would be - "read () on a stringstream causes an infinite loop". Sorry for the 
inconvinience.

Comment 3 Pavel Tsekov 2002-05-20 09:10:32 UTC

Any chance this matter to be reviewed anytime soon ?

Comment 4 Benjamin Kosnik 2004-10-05 16:34:21 UTC

Fixed 3.2.x, 3.3.x, 4.0.x