Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #103381 > unrolled thread

Re: Error message for a dangling pointer

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Error message for a dangling pointer Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-07 09:49 -0700
    Re: Error message for a dangling pointer Manfred <noname@invalid.add> - 2017-02-07 18:42 +0100
      Re: Error message for a dangling pointer Manfred <noname@invalid.add> - 2017-02-07 19:09 +0100
      Re: Error message for a dangling pointer Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-02-07 21:20 -0700

#103381 — Re: Error message for a dangling pointer

ram@zedat.fu-berlin.de (Stefan Ram) writes:

>   For teaching purposes, I just wrote this program to show
>   dangling pointers:
>
> #include <stdio.h>
> int main( void )
> { int * p;
>   { int i = 27; p = &i; }
>   printf( "%d\n", *p ); }
>
>   I hope you all agree that »p« in the last line /is/
>   a dangling pointer.
>
>   The error message and output is not what I expected,
>   but still interesting:
>
> main.c: In function 'main':
> main.c:6:3: warning: 'i' is used uninitialized in this function [-Wuninitialized]
>    printf( "%d\n", *p ); }
>    ^
> main.c:5:9: note: 'i' was declared here
>    { int i = 27; p = &i; }
>          ^
> 0
>
>   »i« /was/ initialized in the program,
>   so the error message is not accurate.
>
>   (I do not write »misleading«, since it is so
>   obviously wrong that it won't mislead anyone.)

I get the message in
gcc (Debian 6.2.1-5) 6.2.1 20161124
if I turn optimization -O1 on.  Also, without optimization the output is
27
while with optimization it is
0

I think we can see the code analysis that's leading to the conclusion
that i is being used uninitialized (*p is being replaced by i, which is
not even defined in the scope in which it is being used, let alone
initialized).

Even without the incorrect warning, I have to wonder how useful an
example of a dangling pointer this would be for students.  Since I'd be
*really* surprised to see an actual implementation really allocate a
stack frame for the inner braces, the lecture would go sort of "see?  A
dangling pointer.  And it does exactly the same thing it would have done
if the pointer weren't dangling. That's why we should avoid dangling
pointers" (and of course that's exactly what happens with gcc, without
optimization).  Coax malloc() into reallocating space you can overwrite
the contents or something....

[toc] | [next] | [standalone]

#103395

On 2/7/2017 5:49 PM, Joe Pfeiffer wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>>   For teaching purposes, I just wrote this program to show
>>   dangling pointers:
>>
<snip>
> I get the message in
> gcc (Debian 6.2.1-5) 6.2.1 20161124
> if I turn optimization -O1 on.  Also, without optimization the output is
> 27
> while with optimization it is
> 0
>
> I think we can see the code analysis that's leading to the conclusion
> that i is being used uninitialized (*p is being replaced by i, which is
> not even defined in the scope in which it is being used, let alone
> initialized).
>
> Even without the incorrect warning, I have to wonder how useful an
> example of a dangling pointer this would be for students.  Since I'd be
> *really* surprised to see an actual implementation really allocate a
> stack frame for the inner braces, the lecture would go sort of "see?  A
> dangling pointer.  And it does exactly the same thing it would have done
> if the pointer weren't dangling. That's why we should avoid dangling
> pointers" (and of course that's exactly what happens with gcc, without
> optimization).  Coax malloc() into reallocating space you can overwrite
> the contents or something....
>
Maybe a dangling pointer assigned (and lost) in a function call could be 
more explicit than with inner braces?
Eventually overwriting the stack frame with a second function call?

[toc] | [prev] | [next] | [standalone]

#103400

On 2/7/2017 6:56 PM, Stefan Ram wrote:
> Manfred <noname@invalid.add> writes:
>> Maybe a dangling pointer assigned (and lost) in a function call could be
>> more explicit than with inner braces?
>> Eventually overwriting the stack frame with a second function call?
>
>   One important aspect of undefined behavior is:
>
>       * it might do what one naïvely expects.
>
>   The participiants of my community education center courses
>   need to see this. Otherwise, after the course they might see
>   that a program does what they expect and might think that
>   its all wrong what I told them because the program does what
>   they expect to instead of doing "something undefined".
>
>   I do not want to mangle reality by artificially forcing the
>   program to fulfill the (naïve?) meta-expectation that UB does
>   something else than naïvely expected.
>
I didn't try it, so this was just speculation, anyway it could probably 
do what you seem to be asking:
- trigger a more clear compiler error/warning
- result in the naive behaviour (if you do /not/ overwrite the stack frame)
- result in an unexpected (for the naive) result (if you /do/ overwrite 
the stack frame)

[toc] | [prev] | [next] | [standalone]

#103428

ram@zedat.fu-berlin.de (Stefan Ram) writes:


> Manfred <noname@invalid.add> writes:
>>Maybe a dangling pointer assigned (and lost) in a function call could be 
>>more explicit than with inner braces?
>>Eventually overwriting the stack frame with a second function call?
>
>   One important aspect of undefined behavior is:
>
>       * it might do what one naïvely expects.
>
>   The participiants of my community education center courses
>   need to see this. Otherwise, after the course they might see
>   that a program does what they expect and might think that
>   its all wrong what I told them because the program does what
>   they expect to instead of doing "something undefined".
>
>   I do not want to mangle reality by artificially forcing the
>   program to fulfill the (naïve?) meta-expectation that UB does
>   something else than naïvely expected.

I can't imagine how "this is undefined behavior that happens to work
this time, but trust me sometimes it breaks" can make the point better
than "this is undefined behavior, watch it break -- of course, sometimes
you get 'lucky' and it works until some later change in compiler
options, compiler version, of phase of the moon".

I guess your example, showing code that "works" without optimization but
breaks when optimization is turned on could be used to make the point,
but from what you've said you aren't doing that.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web