http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
--- Comment #10 from paolo at gcc dot gnu.org
2012-05-23 14:19:37 UTC ---
Author: paolo
Date: Wed May 23 14:19:27 2012
New Revision: 187801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187801
Log:
/cp
2012-05-23 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|gcc-bugs at g
--- Comment #8 from sebor at roguewave dot com 2006-09-28 16:16 ---
The EDG guys don't think this is worth spending the committee's time on so I
won't
be proposing any change to the standard. Issuing just a warning rather than an
error is good enough for me.
Also, I opened bug 29273 to
--- Comment #7 from sebor at roguewave dot com 2006-09-26 21:43 ---
You're right, those weren't the best examples, but I still think they
illustrate the point. The code in them is plain ill-formed even though
it never gets executed, because it just doesn't make sense. deleting
an array a
--- Comment #6 from pinskia at physics dot uc dot edu 2006-09-26 19:00
---
Subject: Re: inconsistent warning: deleting array
>
>
>
> --- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
> You mean something like: if (is_pointer (p)) delete p;
>
> I suppose
>
>
>
> --- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
> You mean something like: if (is_pointer (p)) delete p;
>
> I suppose that could happen but why should it be any different than other
> non-sensical but lexically valid constructs with undefined behavior that
--- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
You mean something like: if (is_pointer (p)) delete p;
I suppose that could happen but why should it be any different than other
non-sensical but lexically valid constructs with undefined behavior that
require a diagnos
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-26 17:42 ---
(In reply to comment #3)
> FWIW, I think it should be ill-formed with diagnostic required since the
> behavior of the expression is always undefined.
There are cases where this can show up in templates, someway or a
--- Comment #3 from sebor at roguewave dot com 2006-09-26 16:31 ---
The response I got from EDG is that the expression is well-formed because of
5, p8. They do agree that issuing a warning would be useful and opened an
enhancement request.
FWIW, I think it should be ill-formed with diag
--- Comment #2 from sebor at roguewave dot com 2006-09-22 16:57 ---
Yes, but 5.3.5, p1 says "The operand shall have a pointer type, or a class
type having a single conversion function (12.3.2) to a pointer type." and
not "shall be convertible to a pointer type." Note that gcc issues a ha
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29185
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-22 16:43 ---
> (ill-fomed?)
I think it is valid because of how arrays decay to pointers (EDG also accepts
the code).
Confirmed, we just do the warning for array type decls:
/* An array can't have been allocated by new, so comp
14 matches
Mail list logo
