Re: libstdc++/3720: Problems with num_get

[bkoz at gcc dot gnu dot org]

The following reply was made to PR libstdc++/3720; it has been noted by GNATS.

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, philip_martin@ntlworld.com,
  schmid@snake.iap.physik.tu-darmstadt.de
Cc:  
Subject: Re: libstdc++/3720: Problems with num_get
Date: 1 Dec 2001 05:17:28 -0000

 Synopsis: Problems with num_get
 
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: bkoz
 State-Changed-When: Fri Nov 30 21:17:27 2001
 State-Changed-Why:
     Hi Peter, Philip. 
     
     I've been thinking about this, and its related bug libstdc++/4402.
     
     I agree this should not core.
     
     Looking at <limits> it looks like the largest number of digits for any numeric input is around 33 characters. 
     
     Looking at the relevant part of the standard, I see
     
     22.2.2.1.2 - num_get virtual functions [lib.facet.num.get.virtuals]
     
     -9- If discard is true then the position of the character is remembered, but the character is otherwise ignored. If it is not discarded, then a check is made to determine if c is allowed as the next character of an input field of the conversion specifier returned by stage 1. If so it is accumulated.
     
     
     This is sufficiently vague to allow the following plan, which I consider sensible:
     
     numbers are extracted while beg != end and while the number of extracted digits <= numeric_limits<_Type>::digits10(). 
     
     At that point, we either continue on without setting failbit, or extract one more and set failbit.
     
     The bit of the standard again:
     
     If it is not discarded, then a check is made to determine if c is allowed as the next character of an input field of the conversion specifier returned by stage 1. If so it is accumulated.
     
     To me, this means that one-past-the type-determined size should be extracted, then not accumulated, and failbit should be set. 
     
     Does this sound reasonable?
     
     -benjamin
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=3720&database=gcc