[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|gcc-bugs at gcc dot gnu.org |
      Known to fail|                            |

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-18 10:26:39 UTC ---
Here we should finally spend a bit of time extending build_typeid to handle
more than INDIRECT_REF: in this case we have a COMPOUND_EXPR, which would be
easy to handle, but we can also have nested COMPOUND_EXPRs... what else?

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |paolo.carlini at oracle dot
                   |gnu.org                     |com

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-31 21:55:13 UTC ---
Looking into it.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com, jason
                   |                            |at gcc dot gnu.org

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-11-01 01:01:07 UTC ---
In fact, I'm not so sure we have a bug here. C++11 5.2.8 says "the expression
is obtained by applying the unary * operator to a pointer and the pointer is a
null pointer value": does that mean *any* possible expression where a null
pointer appears or just the expressions of the simple form clarified in note
68? In fact, if I add:

  polymorphic operator+(polymorphic, polymorphic);

and change the typeid argument to:

  *(T*)0 + *(T*)0

then ICC doesn't throw. Why (result=true, *(T*)0) should be different?

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #8 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-11-01 07:11:56 UTC ---
(In reply to comment #7)
The error is real. The original example belongs to 5.2.8 p2:

"When typeid is applied to a **glvalue expression** whose type is a polymorphic
class type [..] "

which is the rule requiring dynamic evaluation of the expression. Your counter
example is an expression that is an rvalue expression, which belongs to p3:

"When typeid is applied to an expression other than a glvalue of a polymorphic
class type, the result refers to a std::type_info object representing the
static type of the expression. [..] The expression is an unevaluated operand
(Clause 5)."

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #9 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-11-01 08:39:48 UTC ---
Oops, sorry about the rvalue stupid mistake, you are right. Thus I understand
that this type of wording means that assuming it's a glvalue, the null pointer
can appear anywhere, I see. Currentlg we are handling only the examples in the
note.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #10 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-11-01 09:10:56 UTC ---
(In reply to comment #9)
I don't think that the standard says (or intends to say) that an implementation
has to defer all evaluations here. For example, assume you provide

polymorphic& operator+(polymorphic a, polymorphic b);

with some definition this is still UB when the expression

*(T*)0 + *(T*)0

occurs as operand of typeid (Note the arguments are by value). An
implementation is only required to detect whether an (immediate) runtime
glvalue of a polymorphic class as argument of typeid refers to an "empty
glvalue". Anything beyond that would fall under 

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232

I think.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-11-01 11:53:26 UTC ---
I see, thanks Daniel for the additional analysis. Indeed, I can confirm that
with the operator+ return type fixed, ICC doesn't throw either. Now I guess
it's my job to figure out the minimal change getting us the desired behavior...

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #12 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-03-27 10:13:29 UTC ---
I'm having another look to this and apparently clang behaves like GCC.

Jason, what do you think? Should we extend somehow build_typeid? I'm not sure.
In case it would not be very hard, I think.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #13 from Jason Merrill <jason at gcc dot gnu.org> 2013-04-03 17:21:52 UTC ---
I guess it depends on the meaning of "obtained".  If "obtained" refers to the
form of the expression, G++ is following the standard.  If it refers to the
place where the pointer was originally turned into a glvalue, then G++ is
wrong.

I think the best thing to do is to stop looking specifically at the form of the
expression and instead see if the address of the expression is null.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-03 17:27:03 UTC ---
Ah, ah. Thanks Jason.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> 2013-04-09 17:32:49 UTC ---
Mind if I take this one?

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jason at gcc dot gnu.org    |
         AssignedTo|paolo.carlini at oracle dot |jason at gcc dot gnu.org
                   |com                         |

--- Comment #16 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-04-09 17:34:17 UTC ---
Sure.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.9.0

--- Comment #17 from Jason Merrill <jason at gcc dot gnu.org> 2013-04-09 18:49:48 UTC ---
Fixed for 4.9.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[hhinnant at apple dot com]

------- Comment #4 from hhinnant at apple dot com  2005-12-17 22:01 -------
Agreed, (that's brutal ;-) ).

Sorry about the duplicate.  My clumsy fingers hit refresh on my browser and
that generated the duplicate.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-17 21:55 -------
*** Bug 25467 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-17 21:52 -------
So for the following:
#include <iostream>
#include <typeinfo>

const std::type_info *a;

template <class T>
bool is_polymorphic() {
   bool result(false);
   const std::type_info &a1 = typeid( (result=true), *(T*)0);
   a = &a1;
   return result;
}

struct non_polymorphic {};
struct polymorphic { virtual ~polymorphic() {} };


int main() {
   std::cout << is_polymorphic<int>() << '\n';
   std::cout << is_polymorphic<non_polymorphic>() << '\n';
   try
   {
      std::cout << is_polymorphic<polymorphic>() << '\n';              //3
      std::cout << "Fail, should have thrown bad_typeid\n";
   }
   catch (std::bad_typeid&)
   {
      std::cout << "Pass\n";
   }
   catch (...)
   {
      std::cout << "Fail, bad_typeid not caught\n";
   }
}

Should Pass and not just seg fault (if I am reading this correctly).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |2.95.3 4.0.0 3.4.0 3.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-17 21:44 -------
This is a front-end issue:
  <<cleanup_point <<< Unknown tree: expr_stmt  (void) (struct type_info *)
*(((void) (result = 1);  *0B;)._vptr.polymorphic + -4B) >>>>>;

Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|libstdc++                   |c++
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-17 21:44:06
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466