Re: What is the correct behaviour?
Jiang wrote:
James Kanze wrote:
Jiang wrote:
James Kanze wrote:
Jonne Lehtinen wrote:
Hello, I just stumbled upon two different behaviours with two
different compilers. Here's a sample code....
std::string a( "-432" );
unsigned long b = 0;
std::stringstream stream;
if( !(stream << a && stream >> b) ) {
// Should fail?
}
On g++ 4.1.2 (20061026 (Debian "prerelease")) and g++ 3.4.2 it
does indeed fail but on my school's modified g++ 4.1 (uses
stlport 5.0.1) and on Visual C++ 2005 it doesn't fail. Which
behaviour is correct?
It's undefined behavior, but from a quality of implementation
point of view
IMHO, this is implementation-defined behavior.
In 4.7(Integral conversions), the standard says:
If the destination type is signed, the value is unchanged if it
can be represented in the destination type (and bit-field width);
otherwise, the value is implementation-defined.
There's no integral conversion involved. Integral conversions
are between integral types, and do not use the standard library.
But finally the standard library needs the conversion, because
we do not have an integer at the beginning, right?
This is perhaps a bit confusing, because the word "conversion"
is being used for two things that are technically very
different. The standard library must implement a conversion of
text to a numerical value. There is no such conversion in the
language proper. ?4.7 discusses conversions in the language
itself, and not those implemented by the library. And not all
of those: the very first words in the section are "An rvalue of
an integer type can be converted to an rvalue of another integer
type. An rvalue of an enumeration type can be converted to an
rvalue of an integer type." And those are the conversions which
are meant by "Integral conversions". There is no integral
conversion here; the standard also specifies (in various library
sections, and by references to the C library) how a string of
text is converted (at run-time) to an integral type, but
integral conversions have nothing to do with this, except in so
far as the standard says they do.
The istream's extractors uses num_get, which handling
numeric formatting and conversion.
I know. And they define the semantics by reference to fscanf in
the C standard. And the C standard says that if the converted
value isn't representable in the target type, the behavior is
undefined.
Actually I feel strange that we need C language standard to
induce the C++ standard rule (Although I did quote C99 in
this newsgroup for some reasons). Maybe I will post a message
for this issue in comp.std.c++.
The reason is simple. It was definitly the intent of the
committee that the results of such conversions be the same in C
and in C++. And what better way to ensure this than by refering
to the C standard in C++.
As it happens, however, the C standard defines the semantics of
the conversion "as if" strtoul was used. And strtoul defines a
conversion of "-432" to unsigned long; the results must be equal
to ULONG_MAX+1-432. I'd missed this little detail before, but
it would seem that if we take the standard literally, the
conversion is well defined, with well defined results, and an
implementation which reports an error is not conformant.
I don't know for sure whether this is intentional or simply an
accidental result of applying the general principle used to
define signed conversions to unsigned conversions. At any rate,
I'm not yet to the point of posting a bug report to g++ because
they generate an error.
This issue is not clear for me, because the C++ standard
does not say it explicitly that for this issue we should refer
C standard (c90, since C++ standard predates C99 )
Yes it does. The description of the semantics of the num_get
virtual functions, in ?22.2.2.1.2, makes explicit reference to
the stdio conversion specifiers, and in stage three, it says "A
sequence of chars has been accumulated in stage 2 that is
converted (according to the rules of scanf) to a value of the
type of val [...] The sequence of chars accumulated in stage 2
would have caused scanf to report an input failure." The
semantics of the conversion are defined by what scanf would have
done.
[...]
For above Boost lexical_cast test case, following compilers throw
the bad_lexical_cast exception.
1. GCC 4.0.3 ( ubuntu build, libstdc++.so.6 )
2. GCC 3.4.4 ( cygwin build, libstdc++-v3 cygwin port. newlib)
3. Borland c++ 5.5.1
However, the following implementations do not throw exception,
and the cast result is exactly what you said.
1. MS vc7.1
2. MS vc8.0
3. Intel icl 9.0
4. Comeau 4.3.3 ( vc7.1 back-end + libcomo )
Undefined behavior? implementation-defined behavior?
Or simply compiler bugs ?
As currently worded, I don't think an error is allowed in this
specific case. I'm far from sure that this was the intent,
however, and I, personnally, would prefer the error.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]