This is the mail archive of the
mailing list for the libstdc++ project.
Re: request suggestions/proofread for DR
- To: stdc++ <libstdc++ at sourceware dot cygnus dot com>
- Subject: Re: request suggestions/proofread for DR
- From: brent verner <brent at rcfile dot org>
- Date: Wed, 12 Jul 2000 10:12:25 -0400
- References: <firstname.lastname@example.org>
On 12 Jul 2000 at 02:56 (-0700), Dietmar Kuehl wrote:
| --- brent verner <email@example.com> schrieb:
| > I propose the following addition to clarify this situation.
| > Location:
| > 220.127.116.11.2 num_get virtual functions
| > 11 Stage 3: The result of stage 2 processing can be one of
| > Addition:
| > Stage 2 was unable to successfully accumulate and convert
| > any chars to type val. ios_base::failbit is assigned to err.
| > */
| Currently the standard says in 18.104.22.168.2 paragraph 11 second bullet:
| The sequence of chars accumulated in stage 2 would have caused
| scanf to report an input failure. ios_base::failbit
| is assigned to err.
...yeah, It is the 'sequence of chars accumulated' part that is
not, IMO, precise, since the core of my issue is the case when
there is no 'sequence of chars accumulated' at all.
| Track it down and you will see that 'failbit' is set if no characters
| where accumlated in stage 2. I'm not saying that the standard is
well, in our implementation, we never get a chance to set failbit
since, we cant get a good sentry to attempt the do_get again, since
eofbit is already set by (IIRC) bullet #5 of the section in question.
we can cause the desired behavior simply by setting failbit if
a good sentry can not be created... a hack, a QOI issue, ???. It
would just be nice to have something in writing to guarantee that
the desired behavior is _dictated_ by the standard.
after a night's rest, I'm not sure that my proposal would even
_dictate_ the desired consistent behavior. I'll keep this brewing
in the background today at work, so maybe I can get closer to the
heart of the problem.
| reasonably clear about this: Actually it is not. However, the standard
| is consistent and correct and even says exactly what it wants to say
| (at least with respect to this issue; there is an issue with numeric
| overflow and error reporting in C++). Thus, if you would submit this as
| a defect report, the answer of the LWG would be: Not a defect! It is
| not the goal of standard to be clear. The goal is to precisely describe
| something to produce predictable behavior. It would be cool if this
| would be done in a form easily understandable but I don't think that
| clarifications qualify as defects...
darn. I've got to find a real error now :) Either in libstdc++-v3
or in the standard. I'm fairly certain that libstdc++-v3 does
everything required by the standard in the area in question, so
I'm forced to look at the standard further.
Damon Brent Verner o _ _ _
Cracker Jack? Surprise Certified _o /\_ _ \\o (_)\__/o (_)
firstname.lastname@example.org _< \_ _>(_) (_)/<_ \_| \ _|/' \/
email@example.com (_)>(_) (_) (_) (_) (_)' _\o_