memset + free

[dykeinthebox]

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

[Eric Sosman]

dykeinthebox wrote:

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

Since a conforming program cannot tell the difference,
the "as if rule" holds and the compiler is permitted to
delete the memset() call. For that matter, it is allowed
to delete the strcpy(), the if, and the malloc(): none of
them have any influence on the program's observable behavior,
so all of them can be optimized away.

What are you trying to do? Ensure that a password or
similar secret item doesn't show up in a core dump?

--
Eric Sosman
es*****@acm-dot-org.invalid

[Dave Vandervies]

In article <f4**********@n ews6.zwoll1.ov. home.nl>,
dykeinthebox <dy**********@h otrmail.comwrot e:

>Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

I don't believe there's any way that a strictly conforming program can
tell the difference, so the as-if rule allows the compiler to optimize
it away.

What are you Really Trying To Do? (If it's what I think it is, the OS
should be doing it for you.)
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca

Surprise your compiler. Write better code than it asks you to.
--Keith Thompson in comp.lang.c

[Flash Gordon]

dykeinthebox wrote, On 10/06/07 21:39:

Consider the following program:

#include <stdlib.h>
#include <string.h>

int main( void )
{
void *p = malloc( 4 );
if ( p )
{
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming the memory
allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

Since there is no way for a conforming program to tell the difference by
the "as-if" rule it is allowed to optimise out the memset.

If you are looking at this from a security perspective (i.e. you want to
guarantee that someone can't examine memory to get passwords) they I
suggest asking in a security group and/or a group dedicated to your
platform since C does not help you very much.
--
Flash Gordon

[Frodo Baggins]

On Jun 10, 5:10 pm, dj3va...@csclub .uwaterloo.ca (Dave Vandervies)
wrote:

What are you Really Trying To Do? (If it's what I think it is, the OS
should be doing it for you.)

Why? AFAIK the libc should simply put the memory block back on the
free chain(s).

Regards,
Frodo B

[Frodo Baggins]

On Jun 10, 4:39 pm, "dykeintheb ox" <dykeinthe...@h otrmail.comwrot e:

allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

If it is important for memset() to be called, would it improve matters
if the pointer was volatile?
Of course, optimization flags are OT here.

Regards,
Frodo B

[Keith Thompson]

Frodo Baggins <fr*********@gm ail.comwrites:

On Jun 10, 4:39 pm, "dykeintheb ox" <dykeinthe...@h otrmail.comwrot e:

>allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

If it is important for memset() to be called, would it improve matters
if the pointer was volatile?
Of course, optimization flags are OT here.

Probably not, but it might help if the data the pointer points to is
volatile.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Tobin]

In article <f4**********@n ews6.zwoll1.ov. home.nl>,
dykeinthebox <dy**********@h otrmail.comwrot e:

strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );

If the "SEC" here indicates that you're worried about security, you
need to describe just what you're trying to achieve. On a
general-purpose operating system, no other program should be able to
see the data: it will be zeroed before it's allocated to another
program. A user with normal privileges should not be able to
look at it, unless they're running the program.

In theory using volatile might force the write to occur, but in
practice I doubt any compiler does the optimisation anyway - it's hard
to imagine a situation where it would be worthwhile.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[CBFalconer]

dykeinthebox wrote:

>
#include <stdlib.h>
#include <string.h>

int main( void ) {
void *p = malloc( 4 );
if ( p ) {
strcpy( p, "SEC" );
free( memset( p, 0, 4 ) );
}
return 0;
}

Are the characters in the memory block pointed to by p (assuming
the memory allocation succeeded) guaranteed to be set to 0, just
before the memory is being deallocated; or is a compiler allowed
to 'optimize away' the call to memset?

Since, after the free call, nothing can tell the difference, it can
optimize it out.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[Jack Klein]

On Sun, 10 Jun 2007 23:57:37 -0000, Frodo Baggins
<fr*********@gm ail.comwrote in comp.lang.c:

On Jun 10, 4:39 pm, "dykeintheb ox" <dykeinthe...@h otrmail.comwrot e:

allocation succeeded) guaranteed to be set to 0, just before the memory is
being deallocated; or is a compiler allowed to 'optimize away' the call to
memset?

If it is important for memset() to be called, would it improve matters
if the pointer was volatile?
Of course, optimization flags are OT here.

You can't pass a volatile pointer to memset(). memset() only accepts
a non-cv qualified void pointer. To pass a volatile pointer, you must
use a cast to remove the volatile qualifier, and the result is
undefined behavior.

So there is still no reason that the implementation can't optimize
away the call.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html