Printable View
I noticed that every GetSaveFileName/GetOpenFileName example on the web uses the ZeroMemory macro after initializing the OPENFILENAME structure, like this:
My question is why?Code:OPENFILENAME ofn;
ZeroMemory(&ofn,sizeof(ofn));
Why do I need to fill my structure with zeros?
What is OPENFILENAME any different from any other WinAPI structure I initialized before and didn't use ZeroMemory?
Well, Here is an example in MSDN of using GetSaveFileName without ZeroMemory call.
In your code it is the ZeroMemory that initializes a variable of OPENFILENAME structure with 0-s, and not ZeroMemory called after initialization.
The important thing related to GetSaveFileName/GetOpenFileName is that their parameter, which is the pointer to OPENFILENAME structure is the IN/OUT parameter, which implies that some information within the structure should be passed to the functions .
So typically you initialize the structure members with 0-s, then fill some members of the structure (at least first member of the structure lStructSize should be initialized to sizeof(OPENFILENAME), then call the functions.
As a rule of thumb, you have to initialize every local, non-static variable, not only structures.
Actually, you do not have to fill your structure with zeroes. Before that API call some members must NOT be zero.Quote:
Originally Posted by paprica
You could simply set all members that you need one-by-one (as was shown above). But with a large structure, and if you know that most members should be set to 0 anyway, it is easier to use ZeroMemory() first and then set only non-0 members.
That also guarantees that if you did not specifically set some member value, it will be 0. And this is always better than some garbage value.
ZeroMemory(sizeof(ofn)) might cause a crash to your program.
Imagine you have compiled your program with a version of the include file where the size of OPENFILENAME is 40 bytes (I have not counted, this is an example).
And imagine you are running your program on an old Windows version where the size of OPENFILENAME is 32 bytes.
Then, if you ZeroMemory the 40 bytes of the 32-byte long structure, you write 0 in 8 bytes beyond the structure, and this might cause damages.
So you were right to ask yourself the question about ZeroMemory(sizeof(ofn)). My recommendation is: don't do that.
Sorry, but this is just wrong. How would the run-time version of Windows affect the size of ofn determined at compile time?Quote:
Originally Posted by olivthill2
That crash (if any) is out of the responsibility of the developer who uses OPENFILENAME structure. It is the responsibility of the person who designs GetSaveFileName/GetOpenFileName functions and OPENFILENAME structure.Quote:
ZeroMemory(sizeof(ofn)) might cause a crash to your program.
...
If he doesn't take care of backward compatibility of its API, then the crash described can be happen also without ZeroMemory call (for example the structure members and their meaning are totally changed in new version of the structure). Since MS stated, that their API keeps backward compatibility between old and new OS-es, the crash should not be happen. I guess (on old and new Windows) they will just look into the first member of the structure (lStructSize) and if it doesn't match to their expected/supported size, GetSaveFileName/GetOpenFileName function will return FALSE.
Let's consider following situation.Quote:
So you were right to ask yourself the question about ZeroMemory(sizeof(ofn)). My recommendation is: don't do that
ZeroMemory is not called and all members of OPENFILENAME structure are initialized individually.
In the future SDK new member is added into the structure and existing project is recompiled for newer version of the application.
As a result that new member will be uninitialized. So for safety it is always better to initialize the structure with 0-s before initializing members individually.
If this is an issue, then the way out of it is to declare a global and static and initialize your local variables with it.Quote:
Originally Posted by olivthill2
Since globals and statics are zero initialized by default, then this sort of hack should work.Code:static OPENFILENAME dummy;
void foo()
{
OPENFILENAME local = dummy; // zero-initialized
// ...
};
Regards,
Paul McKenzie
No, ZeroMemory(sizeof(ofn)) will not cause a crash of your program but a compiler error because ZeroMemory macro requires 2 arguments.Quote:
Originally Posted by olivthill2
And what about OPENFILENAME local = {0}; ?Quote:
Originally Posted by Paul McKenzie
Yes, that will work also.Quote:
Originally Posted by ovidiucucu
Regards,
Paul McKenzie
The question is really a general one.Quote:
Originally Posted by paprica
When you declare a local variable of any type, unless you're dealing with C++ and the type has a constructor, the values are uninitialized. Since OPENFILENAME is a 'C' type with no user-defined constructor, then declaring an OPENFILENAME within a block of code gives you an OPENFILENAME filled with junk values.
So let's say you didn't initialize all the members, and you send this OPENFILENAME to a function that you have no control over and you didn't write, i.e. a Windows API function. The API function then looks at the OPENFILENAME you passed, and it uses these bogus values to do whatever it needs to do. Then what you have now is an API function that acts erratically, depending on what junk values were in the OPENFILENAME at the time.
You will know when something isn't right when your program behaves differently when you call GetOpenFileName( ). You may have the program working on some days, bombing out on other days, failing on one machine, but working on another machine, etc. Anytime you have a Windows API function not behaving consistently between runs, always check if you're sending a struct, whatever that struct is (in this case it's OPENFILENAME) is initialized with known values.
So that's why ZeroMemory() is called -- to make sure that the struct uses known values, and no invalid values throws off the routine that is going to use the struct. As ovidiucucu pointed out, you can really initialize the struct (which you did not do in your example) by truly initializing it to 0.
But again, you should keep this in mind for any struct you use that eventually will be passed to another function to be processed. If that struct has the potential to have uninitialized members, then you need to be very careful and determine if those uninitialized values can potentially cause erratic behaviour in the program. When in doubt, then set these members to some value (usually the documentation will tell you what these should be set for).Code:OPENFILENAME ofn = {0};
Regards,
Paul McKenzie