Re: integer literals
On Sep 26, 1:49 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Armen Tsirunyan wrote:
Consider the following program
#include <iostream>
#include <typeinfo>
template <class T>
void f(T x)
{
std::cout << typeid(x).name() << std::endl;
}
int main()
{
f(2000000000);
f(3000000000u);
f(3000000000);
}
I am using Microsoft Visual Studio 2008 and on my machine
int and long are both 32 bits. As far as I understood from
the 2003 C++ standard, this program should print
int
unsigned int
unsigned int
however it prints
int
unsigned int
unsigned long
Is this a bug of MSVC9.0 or I have misinterpreted the standard?
From the standard [2.13.1/2]
The type of an integer literal depends on its form, value, and suffix. If
it is decimal and has no suffix, it has the first of these types in which
its value can be represented: int, long int; if the value cannot be
represented as a long int, the behavior is undefined. If it is octal or
hexadecimal and has no suffix ...
The last literal seems to be decimal, without suffix, and not representable
as long int. My reading is that the program has UB.
Now, as a matter of implementation quality, I would strongly expect a
compilation error.
As a matter of implementation quality, I would expect the
compiler to implement long long, and use that.
(The intent is clear: in no case should a decimal constant be
interpreted as signed. The existing practice is just as clear:
use unsigned long is long doesn't fit. The compromise is to
make it undefined behavior, and so allow both.)
--
James Kanze