volatile malloc memory?

[Dan]

What is the correct way to allocate memory that is defined as volatile so
that all standard compilers will not optomise out writes to the memory that
are never read again?

I have some encryption programs that, depending on the
implementation/compiler, part of the code that clears memory at the end of
the program gets optomised away.

[Dan]

"Dan" <vo***@sometwher.worldwrote in message
news:48**********************@news.optusnet.com.au ...

What is the correct way to allocate memory that is defined as volatile so
that all standard compilers will not optomise out writes to the memory
that are never read again?

I have some encryption programs that, depending on the
implementation/compiler, part of the code that clears memory at the end of
the program gets optomised away.

ps. i tried some obvious stuff like specifing the character pointed to as
volatile when assigning to it a value, but it still gets optomised away.

[Johannes Bauer]

Dan schrieb:

ps. i tried some obvious stuff like specifing the character pointed to as
volatile when assigning to it a value, but it still gets optomised away.

Are you sure your code works correctly? I just tried this out:

#include <stdlib.h>

int main() {
char *x;
volatile char *y;

x = malloc(128);
x[0] = 0xaa;
x[0] = 0xbb;
x[0] = 0xcc;
x[0] = 0xdd;

y = malloc(128);
y[0] = 0xaa;
y[0] = 0xbb;
y[0] = 0xcc;
y[0] = 0xdd;

return 0;
}

Which compiles which gcc-4.something and -O3 to the expected result

4004f4: bf 80 00 00 00 mov $0x80,%edi
4004f9: e8 32 ff ff ff callq 400430 <malloc@plt>
4004fe: bf 80 00 00 00 mov $0x80,%edi
400503: c6 00 dd movb $0xdd,(%rax)
400506: e8 25 ff ff ff callq 400430 <malloc@plt>
40050b: c6 00 aa movb $0xaa,(%rax)
40050e: c6 00 bb movb $0xbb,(%rax)
400511: c6 00 cc movb $0xcc,(%rax)
400514: c6 00 dd movb $0xdd,(%rax)

Kind regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electronics <47***********************@news.freenet.de>

[Antoninus Twink]

On 9 May 2008 at 9:25, Johannes Bauer wrote:

volatile char *y;

Possibly the OP had a char *volatile y, giving a volatile pointer to
char, rather than a pointer to volatile char?

[Antoninus Twink]

On 9 May 2008 at 7:36, Dan wrote:

What is the correct way to allocate memory that is defined as volatile
so that all standard compilers will not optomise out writes to the
memory that are never read again?

What compiler are you using? How are you writing to the memory?

Here's a simple program:

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

int main(void)
{
char *x = malloc(128);
memset(x, 0, 128);
free(x);
return 0;
}

Here's the start of the code produced by gcc with -O3 optimization
level:

0x080483e0 <main+0>: lea ecx,[esp+0x4]
0x080483e4 <main+4>: and esp,0xfffffff0
0x080483e7 <main+7>: push DWORD PTR [ecx-0x4]
0x080483ea <main+10>: push ebp
0x080483eb <main+11>: mov ebp,esp
0x080483ed <main+13>: sub esp,0x18
0x080483f0 <main+16>: mov DWORD PTR [ebp-0x8],ecx
0x080483f3 <main+19>: mov DWORD PTR [ebp-0x4],ebx
0x080483f6 <main+22>: mov DWORD PTR [esp],0x80
0x080483fd <main+29>: call 0x8048340 <malloc@plt>
0x08048402 <main+34>: mov DWORD PTR [esp+0x8],0x80
0x0804840a <main+42>: mov DWORD PTR [esp+0x4],0x0
0x08048412 <main+50>: mov ebx,eax
0x08048414 <main+52>: mov DWORD PTR [esp],eax
0x08048417 <main+55>: call 0x8048310 <memset@plt>
0x0804841c <main+60>: mov DWORD PTR [esp],ebx
0x0804841f <main+63>: call 0x8048330 <free@plt>

Notice that even on the highest optimization level, gcc doesn't remove
the call to memset, even with no volatile qualifiers around, and even
though the memory is immediately free()d afterwards.

[vippstar]

On May 9, 3:06 pm, some troll wrote:

On 9 May 2008 at 7:36, Dan wrote:

What is the correct way to allocate memory that is defined as volatile
so that all standard compilers will not optomise out writes to the
memory that are never read again?

What compiler are you using? How are you writing to the memory?

Here's a simple program:

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

int main(void)
{
char *x = malloc(128);
memset(x, 0, 128);
free(x);
return 0;

}

Here's the start of the code produced by gcc with -O3 optimization
level:

<possible gcc output>

Notice that even on the highest optimization level, gcc doesn't remove
the call to memset, even with no volatile qualifiers around, and even
though the memory is immediately free()d afterwards.

It shouldn't; That would make your program succeed even if malloc()
returned NULL, which with your current code is not the case.

[Antoninus Twink]

On 9 May 2008 at 14:01, vi******@gmail.com wrote:

On May 9, 3:06 pm, Antoninus Twink wrote:

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

int main(void)
{
char *x = malloc(128);
memset(x, 0, 128);
free(x);
return 0;

}

[snip]

>Notice that even on the highest optimization level, gcc doesn't remove
the call to memset, even with no volatile qualifiers around, and even
though the memory is immediately free()d afterwards.

It shouldn't; That would make your program succeed even if malloc()
returned NULL, which with your current code is not the case.

Define succeed.

Surely if malloc() returns NULL, then passing a null pointer to memset
will invoke undefined behavior, and "success" is one possible result of
undefined behavior. I know that if you believe the regulars here, then
formatting your hard disk and generating nasal demons are the most
likely consequences of undefined behavior, but out here in the real
world, there are other possibilities...