iostream/cin.fail question

Hi,

below, followed by a question:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>

int main()
{   //signed short x;
    unsigned short x;       
    std::cin>>x;
    if (std::cin.fail())
    	{std::cin.clear();  //flags
    	std::cout<<"fail";
    	std::cin.ignore(32767, '\n'); //
    	}
    else
    {std::cout<<"no fail"<<std::endl;}


The code behaves the same whether x it is signed or unsigned. If x is unsigned shouldn't a negative number cause it to fail?
Last edited on
Did you try displaying x?

x=65535, which is the unsigned short equivalent of -1.

Hi AA

I'm sorry I didn't understand your reply (my fault I believe). Let me discuss from a different angle:

if I make x a signed short, the program detects failure fine: range -32767 to +32767. If x falls out of the range, cin.fail occurs. If I make x an unsigned short 0 to 65535, negative numbers still pass; cin.fail not triggered.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <iostream>

int main()
{
	//unsigned short x;
	  unsigned short x;
    //std::cin>>x;
	std::cin>>x;
    if (std::cin.fail())
    	{std::cin.clear();  //flags
    	std::cout<<"fail";
    	std::cin.ignore(32767, '\n'); //
    	}
    else
    {std::cout<<"no fail"<<std::endl;}

}


Output signed short:

-500 -> ok
-50k -> fail
100 - > ok
50K->fail


Output unsigned short:

...
-3000->!!expect fail 
Last edited on
What behavior do you expect, and why? Did some documentation incorrectly specify the result of passing a negative integer string into the unsigned operator>>?

on cppreference, you can find it by following a link from http://en.cppreference.com/w/cpp/io/basic_istream/operator_gtgt to http://en.cppreference.com/w/cpp/locale/num_get/get where that's mentioned in the description and highlighted in the notes.

In general, unsigned integers never overflow, they wrap around instead, and so unsigned "overflow" is never treated as an error. Signed integers overflow, resulting in undefined behavior. It is always an error to overflow a signed integer, so when signed operator>> would overflow, it sets the failbit.
Last edited on
Hi

I already read the reference prior--I just needed to discuss it with another perspective.

Honestly, the behavior I expected was a cin.fail() for entering a number less than 0 for an unsigned short:0 to 65535.

Why? Simply, its not in the range of the variable (entered value does not fit the variable).
> I expected was a cin.fail() for entering a number less than 0 for an unsigned short:0 to 65535.

Then why don't you try this :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream>

union hybrid_short
{
     signed short sval;
     unsigned short uval;
};

int main()
{
      hybrid_short i1, i2, i3;
      i1.sval = -25000;
      i2.uval = -25000;
      i3.uval = +40536;

      std::cout << "i1.uval == " << i1.uval << std::endl;
      std::cout << "i2.uval == " << i2.uval << std:: endl;
      std::cout << "i3.uval == " << i3.uval << std:: endl;

      return 0;
}


And the output :
i1.uval == 40536
i2.uval == 40536
i3.uval == 40536


As you know, when you are inputting an unsigned, even if you input a negative, the present number is still actually in the valid range of [0..65535]. That's why (cin) never sets fallbit even when you input a negative number for an unsigned.
Then why don't you try this :

Because the relevant case involves undefined behavior.


As you know, when you are inputting an unsigned, even if you input a negative, the present number is still actually in the valid range of [0..65535]. That's why (cin) never sets fallbit even when you input a negative number for an unsigned.

If you input a negative number, the value is clearly not in the range [0, 65535], so it isn't terribly intuitive that it is quietly converted for you.
> Because the relevant case involves undefined behavior.
You mean mine causes undefined behavior?

Neither I noticed something strange nor my program crashed when I ran & tested my program.
You mean mine causes undefined behavior?

Yes.

Neither I noticed something strange nor my program crashed when I ran & tested my program.

You might want to google "undefined behavior in C++".
Topic archived. No new replies allowed.