Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > integer literals

Reply
Thread Tools

integer literals

 
 
Armen Tsirunyan
Guest
Posts: n/a
 
      09-26-2010
Hi all.
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?
Also, please note that I am aware that the standard imposes no
considerable requirements on type_info::name(). So please let's not
say "the output is correct since name can be anything".
Also, if this indeed is a bug of MSVC (this is a bit off-top now) is
there any use reporting that bug to them, I mean do they care?
Thank you in advance for your comments,
Armen Tsirunyan.
 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      09-26-2010
Armen Tsirunyan wrote:

> Hi all.
> 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. The standard also gives license for that (one could even
read it as a requirement) [5/5]:

If during the evaluation of an expression, the result is not
mathematically defined or not in the range of representable
values for its type, the behavior is undefined, unless such an expression
is a constant expression (5.19), in which case the program is ill-formed.


> Also, please note that I am aware that the standard imposes no
> considerable requirements on type_info::name(). So please let's not
> say "the output is correct since name can be anything".
> Also, if this indeed is a bug of MSVC (this is a bit off-top now) is
> there any use reporting that bug to them, I mean do they care?
> Thank you in advance for your comments,
> Armen Tsirunyan.



Best

Kai-Uwe Bux
 
Reply With Quote
 
 
 
 
Armen Tsirunyan
Guest
Posts: n/a
 
      09-26-2010

> 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.
>


Yes, you are right, I just saw the part where it said the first of
int, unsigned int, long, unsigned long, and missed the part which said
that this referred to octal and hexadecimal literals

> Now, as a matter of implementation quality, I would strongly expect a
> compilation error.


How would you expect a compilation error if the standard says it's
undefined behavior?

> The standard also gives license for that (one could even
> read it as a requirement) [5/5]:
>


License for what? For treating undefined behavior as a compilation
error?
Is this true or false? "Undefined behavior refers to syntactically
well-formed programs. The behavior of the program is undefined, not
the behavior of the compiler."

Thanks,
Armen Tsirunyan
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      09-26-2010
Armen Tsirunyan <(E-Mail Removed)>, on 26/09/2010 06:06:12, wrote:

>
>> 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.
>>

>
> Yes, you are right, I just saw the part where it said the first of
> int, unsigned int, long, unsigned long, and missed the part which said
> that this referred to octal and hexadecimal literals
>
>> Now, as a matter of implementation quality, I would strongly expect a
>> compilation error.

>
> How would you expect a compilation error if the standard says it's
> undefined behavior?
>
>> The standard also gives license for that (one could even
>> read it as a requirement) [5/5]:
>>

>
> License for what? For treating undefined behavior as a compilation
> error?
> Is this true or false? "Undefined behavior refers to syntactically
> well-formed programs. The behavior of the program is undefined, not
> the behavior of the compiler."


Kai-Uwe referred to this part in particular:
"unless such an expression is a constant expression (5.19), in which
case the program is ill-formed."

Since in your case we have a constant expressions which cannot be
represented by a long int, a reading of the standard could lead to the
compiler rejecting your compilation unit as ill-formed. Honestly, I
think this is the only reasonable reading.

Please keep attribution lines in place when quoting the messages you're
replying to.

--
Francesco S. Carta
http://fscode.altervista.org
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      09-26-2010
Pete Becker <(E-Mail Removed)>, on 26/09/2010 09:28:10, wrote:

> On 2010-09-26 09:16:30 -0400, Francesco S. Carta said:
>
>> Armen Tsirunyan <(E-Mail Removed)>, on 26/09/2010 06:06:12, wrote:
>>
>>>
>>>> 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.
>>>>
>>>
>>> Yes, you are right, I just saw the part where it said the first of
>>> int, unsigned int, long, unsigned long, and missed the part which said
>>> that this referred to octal and hexadecimal literals
>>>
>>>> Now, as a matter of implementation quality, I would strongly expect a
>>>> compilation error.
>>>
>>> How would you expect a compilation error if the standard says it's
>>> undefined behavior?
>>>
>>>> The standard also gives license for that (one could even
>>>> read it as a requirement) [5/5]:
>>>>
>>>
>>> License for what? For treating undefined behavior as a compilation
>>> error?
>>> Is this true or false? "Undefined behavior refers to syntactically
>>> well-formed programs. The behavior of the program is undefined, not
>>> the behavior of the compiler."

>>
>> Kai-Uwe referred to this part in particular:
>> "unless such an expression is a constant expression (5.19), in which
>> case the program is ill-formed."
>>
>> Since in your case we have a constant expressions which cannot be
>> represented by a long int, a reading of the standard could lead to the
>> compiler rejecting your compilation unit as ill-formed. Honestly, I
>> think this is the only reasonable reading.
>>

>
> Right, in a compiler that strictly enforces C++03's rules. But most
> compilers these days have long long and unsigned long long, and apply
> the C++0x rules for interpreting integer literals; they're the obvious
> analog to the C++03 rules.


My MinGW 4.4.0, despite having long long which (I think) should be
considered more fitting (as the original literal reported by the OP has
no "u" suffix), interprets it as an unsigned long, furthermore it
reports a warning telling that "this decimal constant is unsigned only
in ISO C90".

I have no idea about why it is using a C90 rule here.

--
Francesco S. Carta
http://fscode.altervista.org
 
Reply With Quote
 
Francesco S. Carta
Guest
Posts: n/a
 
      09-26-2010
Pete Becker <(E-Mail Removed)>, on 26/09/2010 10:23:31, wrote:

> On 2010-09-26 10:16:35 -0400, Francesco S. Carta said:
>
>> Pete Becker <(E-Mail Removed)>, on 26/09/2010 09:28:10, wrote:
>>
>>> On 2010-09-26 09:16:30 -0400, Francesco S. Carta said:
>>>
>>>> Armen Tsirunyan <(E-Mail Removed)>, on 26/09/2010 06:06:12, wrote:
>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> Yes, you are right, I just saw the part where it said the first of
>>>>> int, unsigned int, long, unsigned long, and missed the part which said
>>>>> that this referred to octal and hexadecimal literals
>>>>>
>>>>>> Now, as a matter of implementation quality, I would strongly expect a
>>>>>> compilation error.
>>>>>
>>>>> How would you expect a compilation error if the standard says it's
>>>>> undefined behavior?
>>>>>
>>>>>> The standard also gives license for that (one could even
>>>>>> read it as a requirement) [5/5]:
>>>>>>
>>>>>
>>>>> License for what? For treating undefined behavior as a compilation
>>>>> error?
>>>>> Is this true or false? "Undefined behavior refers to syntactically
>>>>> well-formed programs. The behavior of the program is undefined, not
>>>>> the behavior of the compiler."
>>>>
>>>> Kai-Uwe referred to this part in particular:
>>>> "unless such an expression is a constant expression (5.19), in which
>>>> case the program is ill-formed."
>>>>
>>>> Since in your case we have a constant expressions which cannot be
>>>> represented by a long int, a reading of the standard could lead to the
>>>> compiler rejecting your compilation unit as ill-formed. Honestly, I
>>>> think this is the only reasonable reading.
>>>>
>>>
>>> Right, in a compiler that strictly enforces C++03's rules. But most
>>> compilers these days have long long and unsigned long long, and apply
>>> the C++0x rules for interpreting integer literals; they're the obvious
>>> analog to the C++03 rules.

>>
>> My MinGW 4.4.0, despite having long long which (I think) should be
>> considered more fitting (as the original literal reported by the OP
>> has no "u" suffix), interprets it as an unsigned long, furthermore it
>> reports a warning telling that "this decimal constant is unsigned only
>> in ISO C90".
>>
>> I have no idea about why it is using a C90 rule here.

>
> Hmm, I don't either. The rule in C++0x is the first that fits from int,
> long int, long long int. Well, maybe gcc hasn't implemented the C++0x
> rules yet.


That really seems to be so: using compiler flags such as -std=c++0x or
-std=gnu++0x don't change anything, that warning still gets raised and
that literal still gets interpreted as an unsigned long.

--
Francesco S. Carta
http://fscode.altervista.org
 
Reply With Quote
 
Alf P. Steinbach /Usenet
Guest
Posts: n/a
 
      09-26-2010
* Francesco S. Carta, on 26.09.2010 16:40:
> Pete Becker <(E-Mail Removed)>, on 26/09/2010 10:23:31, wrote:
>
>> Hmm, I don't either. The rule in C++0x is the first that fits from int,
>> long int, long long int. Well, maybe gcc hasn't implemented the C++0x
>> rules yet.

>
> That really seems to be so: using compiler flags such as -std=c++0x or
> -std=gnu++0x don't change anything, that warning still gets raised and that
> literal still gets interpreted as an unsigned long.


I can confirm that for MinGW g++ 4.4.1.


Cheers,

- Alf

--
blog at <url: http://alfps.wordpress.com>
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-26-2010
Pete Becker <(E-Mail Removed)> wrote:
> behavior, such as might arise upon use of an erroneous program
> construct or erroneous data, for which this International Standard
> imposes no requirements. Undefined behavior may also be expected
> when this International Standard omits the description of any explicit
> definition of behavior. [Note: permissible undefined behavior ranges
> from ignoring the situation completely with unpredictable results, to
> behaving during translation or program execution in a documented
> manner characteristic of the environment (with or without the
> issuance of a diagnostic message), to terminating a translation
> or execution (with the issuance of a diagnostic message). Many
> erroneous program constructs do not engender undefined behavior;
> they are required to be diagnosed. ??? end note ]


Btw, what's the standard definition of "ill-formed"?
 
Reply With Quote
 
Armen Tsirunyan
Guest
Posts: n/a
 
      09-26-2010
> * Btw, what's the standard definition of "ill-formed"?

the 2003 standard clause 1.3.14 defines "well-formed program":
A C++ program constructed according to the syntax rules, diagnosable
semantic rules, and the One Definition Rule.

I guess a program is ill-formed if it is not well-formed. Am I right?
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      09-26-2010
Juha Nieminen wrote:

> Pete Becker <(E-Mail Removed)> wrote:
>> behavior, such as might arise upon use of an erroneous program
>> construct or erroneous data, for which this International Standard
>> imposes no requirements. Undefined behavior may also be expected
>> when this International Standard omits the description of any
>> explicit definition of behavior. [Note: permissible undefined
>> behavior ranges from ignoring the situation completely with
>> unpredictable results, to behaving during translation or program
>> execution in a documented manner characteristic of the environment
>> (with or without the issuance of a diagnostic message), to
>> terminating a translation or execution (with the issuance of a
>> diagnostic message). Many erroneous program constructs do not
>> engender undefined behavior; they are required to be diagnosed.
>> ??? end note ]

>
> Btw, what's the standard definition of "ill-formed"?


Not well-formed

From the standard [1.3.4]:

1.3.4 ill-formed program [defns.ill.formed]
input to a C++ implementation that is not a well-formed program (1.3.14).


Best

Kai-Uwe Bux

Just in case you now wonder what a well-formed program is:

1.3.14 well-formed program [defns.well.formed]
a C++ program constructed according to the syntax rules, diagnosable
semantic rules, and the One Definition Rule (3.2).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
negative integer literals Ivan Novick C++ 15 12-10-2006 09:24 PM
Integer Literals bradeck@gmail.com C++ 5 10-19-2006 02:31 PM
Java: byte literals and short literals John Goche Java 8 01-17-2006 11:12 PM
Template argument deduction on integer literals Bart Samwel C++ 14 04-22-2005 10:03 PM
Generic class literals - e.g,, Class<Map<String, Integer>>.class Purush Java 4 04-13-2005 08:40 PM



Advertisments