This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/3720: Problems with num_get
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: bkoz at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 10 Dec 2001 07:46:01 -0000
- Subject: Re: libstdc++/3720: Problems with num_get
- Reply-to: Benjamin Kosnik <bkoz at redhat dot com>
The following reply was made to PR libstdc++/3720; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: Philip Martin <philip@codematters.co.uk>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
schmid@snake.iap.physik.tu-darmstadt.de
Subject: Re: libstdc++/3720: Problems with num_get
Date: Sun, 9 Dec 2001 23:39:04 -0800 (PST)
> would deduce octal from the leading zero, as that's what stdio "%i"
> does. Investigation shows that it is reading decimal, which is then
stdio %i is equiv behavior to basefield == 0 case only. Default is
signed/unsigned int in the case.
> causes the number to be read correctly. I suppose it's table 89 in
> 27.4.4.1 that determines that dec is the default? I didn't expect
> that.
See
22.2.2.1.2 - num_get virtual functions [lib.facet.num.get.virtuals]
p4
on how input is ordered.
For this case, I believe current behavior is correct.
best,
benjamin