Latest Beta

[Ascend4nt]

Okay, I'm totally confused about the 'align' directive now (testing now on 3.3.7.4). Once a 2nd align is encountered, whether inside a nested Struct/EndStruct, the rest of the inner and outer structs follow the alignment.

Examples - 1st results in 11 bytes, 2nd result (without the 2nd align) is 16 bytes:

$sStruct="double outer1; STRUCT; byte inner1; align 1;char inner2; ENDSTRUCT; char outer2"
$stStr = DllStructCreate($sStruct)
ConsoleWrite("Structure size:"&DllStructGetSize($stStr)&@CRLF)

$sStruct="double outer1; STRUCT; byte inner1; char inner2; ENDSTRUCT; char outer2"
$stStr = DllStructCreate($sStruct)
ConsoleWrite("Structure size:"&DllStructGetSize($stStr)&@CRLF)

*edit: Note - Remove the Struct/EndStruct directives and the same size is returned

Edited May 28, 2011 by Ascend4nt

[Jon]

Yeah. From previous discussions there are two options:

1. "pop" the align at the end of a struct (what I was doing)

2. Keep the align (what I am doing now)

The C compilers seemed to be doing 2.

[Jon]

Oh, so it's a bug in AutoIt itself in one of the betas that only happens with x64? In other words, AutoIt is broke, not the script.

Yeah, totally. The only things that should ever break x64 scripts are bad structs and dllcalls really. </in theory>

Urgh. Found the 6 lines that cause the problem - except they are correct so it makes no sense >.<

[Jon]

So, StringFormat is fatally broken in 3.3.7.4 - I'll release an update in the next half an hour or so. It was actually broken on both x86 and x64 but due to flukes it wasn't manifesting on x86 (on my machine at least).

[Jon]

3.3.7.5 (28th May, 2011) (Beta)

- Fixed: StringFormat memory error introduced in 3.3.7.3.

[Richard Robertson]

I'm interested to know what you mean by fatally.

[Jon]

I'm interested to know what you mean by fatally.

It shouldn't work, and only does by chance memory corruption.

[Richard Robertson]

How long has it been broken? Just in that revision?

Edited May 29, 2011 by Richard Robertson

[water]

According to Jon's it was introduced with 3.3.7.3.

[Yashied]

What is wrong with Label? If you pass an empty string and does not specify the height (fifth parameter), the size will be wrong.

GUICreate('MyGUI', 200, 100)
GUICtrlCreateLabel('', 10, 10, 180)
GUICtrlSetBkColor(-1, 0xFF0000)
GUISetState()

Do
Until GUIGetMsg() = -3

Edited May 29, 2011 by Yashied

[Jon]

What is wrong with Label? If you pass an empty string and does not specify the height (fifth parameter), the size will be wrong.

GUICreate('MyGUI', 200, 100)
GUICtrlCreateLabel('', 10, 10, 180)
GUICtrlSetBkColor(-1, 0xFF0000)
GUISetState()

Do
Until GUIGetMsg() = -3

Hmm, at a loss on this one. I just reverted my source tree back to the production version and recompiled and it doesn't work there either. Maybe it's an old hidden bug that's now being shown up in the new compiler...

[Jon]

Hmm, at a loss on this one. I just reverted my source tree back to the production version and recompiled and it doesn't work there either. Maybe it's an old hidden bug that's now being shown up in the new compiler...

Yes, this was the case. An uninitialised variable was usually 0 on the old compiler, it wasn't on the new one and so bad things happened.

[Zedna]

Yes, this was the case. An uninitialised variable was usually 0 on the old compiler, it wasn't on the new one and so bad things happened.

This kind of expecting 0 as unitialized value can be on many places I think.

[czardas]

Yes, this was the case. An uninitialised variable was usually 0 on the old compiler, it wasn't on the new one and so bad things happened.

Out of curiosity, what value (if any ) does an uninitialised variable have on the new compiler?

[ProgAndy]

Out of curiosity, what value (if any ) does an uninitialised variable have on the new compiler?

An uninitialised variable just reserves some memory. Since the part of the memory can contain remains of old data, this will be the "value". Maybe an implicit "initialise to zero" was dropped in favor of speed in the new compiler.

[czardas]

An uninitialised variable just reserves some memory. Since the part of the memory can contain remains of old data, this will be the "value". Maybe an implicit "initialise to zero" was dropped in favor of speed in the new compiler.

Thanks, that's a very clear answer.

[Jon]

The old compiler didn't actively zero variables either, it's all just pure chance.

[James]

The old compiler didn't actively zero variables either, it's all just pure chance.

So what you're saying is using VC10 to compile AutoIt will produce loads of errors because you weren't forewarned by them in the previous versions?

Does this mean AutoIt is now potentially flawed in several places?

[Jon]

No, I'm saying that AutoIt (as all C programs) may have subtle bugs because some variables were left uninitialised and have yet to be discovered due to pure chance of the combination of OS/Compiler/Memory/Previous exes ran. In this case it looks like the author thought that this variable didn't need initialising because the logic of the following code would always assign it a value. That assumption was incorrect if it was passed a blank string.

VC9 didn't initialise variables to 0 either, it's just luck that in this case, for whatever reason, it consistently picked an area of memory that just happened to be 0 to store the variable. We had similar bugs whenever we moved from compiler to compiler before.

But as least we don't have to worry about running another program on our code to check for these sorts of errors, eh, James? (Edit: Or was it Richard who made that comment? I forget)

Edited May 29, 2011 by Jon

[Jon]

3.3.7.6 (29th May, 2011) (Beta)

- Fixed: Include parsing bug introduced in 3.3.7.3

- Fixed: GUICtrlCreateLabel() related text sizing bug when no height was used.