[Bug c/50476] Warn of pointer set to object whose lifetime is limited

2019-08-05 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476
Bug 50476 depends on bug 60517, which changed state.

Bug 60517 Summary: warning/error for taking address of member of a temporary 
object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c/50476] Warn of pointer set to object whose lifetime is limited

2019-08-04 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476

--- Comment #5 from Eric Gallager  ---
would this proposed warning go under an existing flag, or a new one?

[Bug c/50476] Warn of pointer set to object whose lifetime is limited

2015-09-17 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-17
 Depends on||60517
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
Possibly a duplicate of PR60517, but this testcase is slightly different (it
involves assigning to global pointer and not a return statement).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
[Bug 60517] warning/error for taking address of member of a temporary object

[Bug c/50476] Warn of pointer set to object whose lifetime is limited

2012-05-09 Thread rui.maciel at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476

--- Comment #3 from Rui Maciel  2012-05-09 
11:47:49 UTC ---
(In reply to comment #2)
> I think it is only undefined behaviour to access the pointer after the
> life-time of y has finished, however, the following probably isn't, no?
> 
> void g()
> {
>   ...
>*x = 2;
>...
> }

As x hasn't been declared at that point, it should throw a compiler error.

If x was a global pointer which was declared previously then a similar problem
would arise.  Take, for example, the following code:


#include 

int *x = 0;

void f(void)
{
int a = 2;
x = &a; 
}

int main(void)
{
f();

printf("Value: %d\n",*x);

return 0;
}


Again, x is set to the address of a local variable, which is then accessed at a
point where the local variable's lifetime has ended.  This behaviour is
explicitly left undefined in ISO 9899:1999 6.2.4 2.  Therefore, it would be
nice if the compiler warned about that.


> void f()
> {
>...
>x = &y;
>...
>g();
>...
>x = NULL;
> }
> 
> The C/C++ FE cannot distinguish between these two cases. 
> 
> Do you have a suggestion about how to implement this? 

>From the user's point of view, it would be nice if the compiler warned if an
object was being accessed after its lifetime.  This should happen at least when
the user explicitly specified the use of a standard which stated that this
behaviour is undefined.

Granted, this might not be an easy thing to implement.  As I don't have any
knowledge on gcc's inner workings, I'm not in a position to suggest how this
might be done.


[Bug c/50476] Warn of pointer set to object whose lifetime is limited

2012-05-09 Thread manu at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  2012-05-09 
11:05:39 UTC ---
I think it is only undefined behaviour to access the pointer after the
life-time of y has finished, however, the following probably isn't, no?

void g()
{
  ...
   *x = 2;
   ...
}

void f()
{
   ...
   x = &y;
   ...
   g();
   ...
   x = NULL;
}

The C/C++ FE cannot distinguish between these two cases. 

Do you have a suggestion about how to implement this? 

I think it would require some kind of constant propagation to know that the
final value of x is safe, but no existing contributor is interested in
implementing such thing, so someone new has to step up and do the work.


[Bug c/50476] Warn of pointer set to object whose lifetime is limited

2012-05-08 Thread rui.maciel at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476

--- Comment #1 from Rui Maciel  2012-05-08 
13:35:33 UTC ---
This issue is still present in gcc 4.6.3.