Is there an alternative solution to this? [Solved]
-
there's also ZeroMemory and memset, but they do the same thing your for loop does.
-
there's also ZeroMemory and memset, but they do the same thing your for loop does.
Paranoid people like me tend to use SecureZeroMemory[^], "as the compiler can optimize a call to
ZeroMemoryby removing it entirely". Makes me think of this article: Optimization: Your Worst Enemy[^] ;)cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy." -
Paranoid people like me tend to use SecureZeroMemory[^], "as the compiler can optimize a call to
ZeroMemoryby removing it entirely". Makes me think of this article: Optimization: Your Worst Enemy[^] ;)cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy."SecureZeroMemory(...)should not really be used for first initialization of a buffer, because if you usememset(...)right before you use the buffer, the call tomemset(...)will not be optimized away. You useSecureZeroMemory(...)in situations where you are clearing a buffer AFTER its use. For example, if you decode/decrypt something into a buffer, and you want to make sure that the plaintext is not lying around in memory somewhere so you clear the buffer before deallocating it (or exiting the function). It is situations where the last thing you do to the buffer is callmemset(...)on it where it can get optimized away. Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
Hi all, the other day someone asked about intializing a buffer (this post)[^]). Today I have had more or less the same problem, but with a pointer. The case is: I have a fixed area of data available to write data in a PLC, but the data itself can be variable (Area = 4096 Bytes, data = [64 ~ 4096]). The length depends on the actual project opened in the application. As the data in the PLC are permanent and a project may be shorter than another, I want to ensure empty values in the rest of the destiny that are over the length of the actual project. (I hope you can understand what I mean). With a normal buffer like in the post of the other day is:
BYTE Buffer [BUF_LENGTH] = {0};
but a pointer created with
newis fulled of "I" = 240 = 0xCD. As I want to have "0", I am now using:nBufLength = nTotalArea - nValidWrittenData;
BYTE* pBuffer = NULL;
pBuffer = new BYTE [nBufLength];
for (int i = 0; i < nBufLength; i++)
*(pBuffer + i) = 0;Which other possibilities can I use / do you recommend to write "0" in the whole buffer? -- modified at 7:18 Thursday 18th October, 2007
Greetings. -------- M.D.V. If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you ;)
memset(...)will be a better alternative because it is optimized - setting individual bytes to zero is slower than setting 32-bit units to zero(on a 32-bit system).memset(...)should walk the buffer byte-by-byte until it gets to a 32-bit boundary and will then increase its stride to 32-bit (4 bytes) units till it gets to the end (slowing back to byte-by-byte if neccessary if the end of the buffer is not on a 32-bit boundary). As an aside, using the bracket notation may produce better performance than manually calculating a pointer offset as aliasing can hinder optimization:for (int i = 0; i < nBufLength; i++)
{
pBuffer[ i ] = 0;
}Oh, and BTW - the buffer is filled with those
0xCDcharacters only in debug builds. In release builds, and in the absence of any memory-allocation utility/library being used, that memory may be filled with random garbage. I only mention this because I have actually seen developers look for the debugger-specific values in a buffer to try to determine if uninitialized memory is being used, or if they are off the beginning or end of a buffer(!!:wtf:!!). Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
memset(...)will be a better alternative because it is optimized - setting individual bytes to zero is slower than setting 32-bit units to zero(on a 32-bit system).memset(...)should walk the buffer byte-by-byte until it gets to a 32-bit boundary and will then increase its stride to 32-bit (4 bytes) units till it gets to the end (slowing back to byte-by-byte if neccessary if the end of the buffer is not on a 32-bit boundary). As an aside, using the bracket notation may produce better performance than manually calculating a pointer offset as aliasing can hinder optimization:for (int i = 0; i < nBufLength; i++)
{
pBuffer[ i ] = 0;
}Oh, and BTW - the buffer is filled with those
0xCDcharacters only in debug builds. In release builds, and in the absence of any memory-allocation utility/library being used, that memory may be filled with random garbage. I only mention this because I have actually seen developers look for the debugger-specific values in a buffer to try to determine if uninitialized memory is being used, or if they are off the beginning or end of a buffer(!!:wtf:!!). Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesThanks for both answers. I have learned someting new. End result is:
nBufLength = nTotalArea - nValidWrittenData;
BYTE* pBuffer = NULL;
pBuffer = new BYTE [nBufLength];
memset (pBuffer, 0, nBufLength);Greetings. -------- M.D.V. If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you ;)
-
SecureZeroMemory(...)should not really be used for first initialization of a buffer, because if you usememset(...)right before you use the buffer, the call tomemset(...)will not be optimized away. You useSecureZeroMemory(...)in situations where you are clearing a buffer AFTER its use. For example, if you decode/decrypt something into a buffer, and you want to make sure that the plaintext is not lying around in memory somewhere so you clear the buffer before deallocating it (or exiting the function). It is situations where the last thing you do to the buffer is callmemset(...)on it where it can get optimized away. Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesYou're right, it should definitely be used for clearing e.g. passwords from memory. But where did you get the info that an initial
memset(...)/ZeroMemory(...)is never optimized away? Furthermore I cannot see any info on MSDN that it's a no-go to do the first initialization withSecureZeroMemory(...). Just a speed issue - saving 42 CPU cycles? ;)cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy." -
You're right, it should definitely be used for clearing e.g. passwords from memory. But where did you get the info that an initial
memset(...)/ZeroMemory(...)is never optimized away? Furthermore I cannot see any info on MSDN that it's a no-go to do the first initialization withSecureZeroMemory(...). Just a speed issue - saving 42 CPU cycles? ;)cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy."The optimization that can remove the last
memset(...)is based on whether or not the memory beingmemset(...)is ever read after being written to (bymemset(...)). In cases of initialization, you can safely usememset(...)because you will be reading the memory at some point after the initial call tomemset(...)(well, at least you would be in general). By usingmemset(...)to clear after use, when you are all done with the memory, if you do not read from that memory again, the optimizer assumes that if you never read what you wrote, you did not need to write it, and can optimize away the call. Cycle counting only makes sense when you know your target hardware. Without knowing the actual differences in what SecureZeroMemory(...) actually has to do behind the scenes (e.g. does it have to read each and every byte/32-bit value it writes to), it is safer to assume that if you do not need the assurances that it provides, you do not need to use the function. Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
The optimization that can remove the last
memset(...)is based on whether or not the memory beingmemset(...)is ever read after being written to (bymemset(...)). In cases of initialization, you can safely usememset(...)because you will be reading the memory at some point after the initial call tomemset(...)(well, at least you would be in general). By usingmemset(...)to clear after use, when you are all done with the memory, if you do not read from that memory again, the optimizer assumes that if you never read what you wrote, you did not need to write it, and can optimize away the call. Cycle counting only makes sense when you know your target hardware. Without knowing the actual differences in what SecureZeroMemory(...) actually has to do behind the scenes (e.g. does it have to read each and every byte/32-bit value it writes to), it is safer to assume that if you do not need the assurances that it provides, you do not need to use the function. Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesMakes perfectly sense... thanks for the answer! :rose: No FUD anymore when initializing memory! But tell me one more thing: Is this behavior your personal experience or where did you get that deep knowledge of code optimization?
cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy." -
Makes perfectly sense... thanks for the answer! :rose: No FUD anymore when initializing memory! But tell me one more thing: Is this behavior your personal experience or where did you get that deep knowledge of code optimization?
cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy."This kind of knowledge and wisdom is based on what I have learned, what I have done, and both together. Most of my professional development has been with server-side development for financial-related products, so I learned very quickly that the stuff you get away with on the client side just does not cut it on the server side. Taking .5 seconds longer than necessary to do something when the market is moving away from you can cost real $$$ in the real world. So I spend much of my professional development life researching things like CPU architecture and code-level optimization techniques so that when milliseconds count, people can count on me. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
This kind of knowledge and wisdom is based on what I have learned, what I have done, and both together. Most of my professional development has been with server-side development for financial-related products, so I learned very quickly that the stuff you get away with on the client side just does not cut it on the server side. Taking .5 seconds longer than necessary to do something when the market is moving away from you can cost real $$$ in the real world. So I spend much of my professional development life researching things like CPU architecture and code-level optimization techniques so that when milliseconds count, people can count on me. Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFilesKudos! Keep on rocking! What's making CodeProject so precious are experts like you! I mean real experts. Not those C# experts (if you feel insulted, insert VB) who think they are experts because they don't know anything else.
cheers! mykel
OMM: "Let us be thankful we have an occupation to fill. Work hard, increase production, prevent accidents and be happy."