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

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

[rui.maciel at gmail dot com]

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

             Bug #: 50476
           Summary: Warn of pointer set to object whose lifetime is
                    limited
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rui.maciel@gmail.com


Consider the following code:

<code>
#include <stdio.h>

int *x = NULL;

void f(void)
{
        int y = 1;

        x = &y;
}


int main(void)
{
        f();

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

        return 0;
}

</code>

Function f() assigns a global pointer to a local object, so that the global
pointer refers to the local object's address even when the object's lifetime
ends.  This represents undefined behaviour, and therefore can be a potential
source of problems.  It would be great if gcc at least threw a warning
informing the user of this problem, similar to how Bug 14156 handles it's use
case.

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

[rui.maciel at gmail dot com]

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

--- Comment #1 from Rui Maciel <rui.maciel at gmail dot com> 2012-05-08 13:35:33 UTC ---
This issue is still present in gcc 4.6.3.

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 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

[rui.maciel at gmail dot com]

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

--- Comment #3 from Rui Maciel <rui.maciel at gmail dot com> 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:

<code>
#include <stdio.h>

int *x = 0;

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

int main(void)
{
        f();

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

        return 0;
}
</code>

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.