On Wed, November 15, 2006 5:02 pm, Andrew Talbot wrote:
- static const WCHAR szProperty[] = {
- static WCHAR szProperty[] = { '{','D','0','F','C','A','4','2','0',
If they aren't constant, shouldn't they be non-static too?
Dimi Paun wrote:
On Wed, November 15, 2006 5:02 pm, Andrew Talbot wrote:
- static const WCHAR szProperty[] = {
- static WCHAR szProperty[] = { '{','D','0','F','C','A','4','2','0',
If they aren't constant, shouldn't they be non-static too?
Hi Dimi,
As I understand it, declaring them static means that the storage will be assigned and initialised at compile time, rather than run time, since the size and contents are already known.
-- Andy.
On Thu, November 16, 2006 12:42 pm, Andrew Talbot wrote:
As I understand it, declaring them static means that the storage will be assigned and initialised at compile time, rather than run time, since the size and contents are already known.
Correct. However, if they aren't constant, it means that they may get modified, which is an obvious problem. Making them non-static would indeed initialize them at runtime (small cost), but they would be guaranteed to have the value that we expect always.
I haven't looked at the code, maybe you can prove they are indeed constant, but that's ugly. I'd take the trivial runtime hit, for the sake of cleanliness.
Dimi Paun wrote:
On Thu, November 16, 2006 12:42 pm, Andrew Talbot wrote:
As I understand it, declaring them static means that the storage will be assigned and initialised at compile time, rather than run time, since the size and contents are already known.
Correct. However, if they aren't constant, it means that they may get modified, which is an obvious problem. Making them non-static would indeed initialize them at runtime (small cost), but they would be guaranteed to have the value that we expect always.
I haven't looked at the code, maybe you can prove they are indeed constant, but that's ugly. I'd take the trivial runtime hit, for the sake of cleanliness.
I did run this by Alexandre at one point, because this concern was expressed to me by one or two other prominent members of the Wine community, and he said "They should be static always, there's no reason to make the compiler create a separate copy at run-time, which will happen with automatic variables." The hit is not so much in the initialisation as in the creation of the storage, which has to take place for each invocation.
Making the variables automatic guarantees that they will be correct at the start of each invocation of the function they are in, but doesn't guarantee that another function with non-const formal parameters that it, in turn, calls won't mess them up during that invocation, and the reason why we are deconstifying logically-constant variables is that we are passing them to non-const-correct C standard library or SDK functions. So once you take away the const qualifier from a variable it will be vulnerable to potential corruption by a bad sub-function, whether that variable is automatic or static.
I make these assertions in humble recognition of the fact that I could be speaking from a position of profound ignorance. In the end, my confidence rests in the firm belief that Alexandre would reject this form of fix if he considered it unacceptable.
-- Andy.
-
Andrew Talbot -
Dimi Paun