Possible problems with SSE usage.

[Queue]

Yes, and I've done hex comparisons, byte-for-byte. I'm definitely working with the same version of ML as you.

Queue

[sinsi]

Any alignment of the stack beyond the default 4 bytes will have to be done with some sort of code, a custom prologue for example, you can't just automatically align it.
If that was the case then we poor ml64 users would have it a lot easier...

[KeepingRealBusy]

Sinsi,

Thank you for the information. That is exactly what I did, but wondered what else could be done to eliminate the 3 instructions it takes to do this.

Dave.

Well now I know where I stand.  :wink

I am not an expert at SSE, but what's wrong with ALIGN 16 to align the LOCALs?

Greg,

ALIGN 16 is an assembly time directive, it just adjusts the address at which the next data or instruction will be located, and in the case of instructions, it pads the code with dummy instructions that do not affect either the registers or the flags (instructions like lea ebx,[ebx]). What I needed was something to reserve space in the stack, and also something to selectively, at execution time, select the actual stack address to use for an aligned store (movdqa). It turns out that you must do this yourself since the stack can be aligned differently at each call.

I guess I will have to time this both ways, using code to align for a movdqa, or no code and use movdqu.

Dave.

[GregL]

Dave,

I see, I thought you wanted to align the OWORD data variables. Sorry, I misunderstood.


dedndave Dave,

I was kidding, hence the wink.  I am not as sharp as I used to be, some of these guys run circles around me.

[dedndave]

shoot, Greg - some of the newbies can make me look bad - lol

[KeepingRealBusy]

Well, here is my final version of WordAlign, actually KRBWordAlign (both functions are there, KRBWordAlign is tested) The KRBWordAlign version has the code shuffled around as much as possible to confuse the reader, WordAlign might be easier to understand. The attached zip contains modified tests that test all 32768 different lengths of a wide character test string, all stuffed at the end of a VirtualAlloc buffer with an odd BYTE start. Three error return conditions are tested.

Dave.

[ecube]

Exceptions are for exceptional events, and only ones that the local procedure can't handle and are otherwise unwieldy to transmit back to the caller through normal return mechanics.

If your code is *expecting* an exception, there is something wrong.

that's not true, various protection methods are based off SEH such as nanomites, page guards, some vm engines, etc... also it can help prevent malicious attacks in security software by handling errors calmly vs it blowing up in your face, and is used in detecting vm machines like vmware. It's good for self debugging aswell.

[Rockoon]

Exceptions are for exceptional events, and only ones that the local procedure can't handle and are otherwise unwieldy to transmit back to the caller through normal return mechanics.

If your code is *expecting* an exception, there is something wrong.

that's not true, various protection methods are based off SEH such as nanomites, page guards, some vm engines, etc... also it can help prevent malicious attacks in security software by handling errors calmly vs it blowing up in your face, and is used in detecting vm machines like vmware. It's good for self debugging aswell.

You are not *expecting* an exception in normal code execution with those things. You are expecting exceptions in *abnormal* execution in most of them, and in the other are trying to intentionally create abnormal behavior.

Rare events are not part of normal flow control.

Exceptions dont help you debug anything when you are using them for flow control. They make it much much harder. You could have checked the size of the buffer, but intead you waited for an exception.. really? thats easier to debug?

[ecube]

Exceptions are for exceptional events, and only ones that the local procedure can't handle and are otherwise unwieldy to transmit back to the caller through normal return mechanics.

If your code is *expecting* an exception, there is something wrong.

that's not true, various protection methods are based off SEH such as nanomites, page guards, some vm engines, etc... also it can help prevent malicious attacks in security software by handling errors calmly vs it blowing up in your face, and is used in detecting vm machines like vmware. It's good for self debugging aswell.

You are not *expecting* an exception in normal code execution with those things. You are expecting exceptions in *abnormal* execution in most of them, and in the other are trying to intentionally create abnormal behavior.

Rare events are not part of normal flow control.

Exceptions dont help you debug anything when you are using them for flow control. They make it much much harder. You could have checked the size of the buffer, but intead you waited for an exception.. really? thats easier to debug?

actually again that's not true, in the case of nanomites it intentionally puts exception code in the place of say calls so that when the program comes across it, it throws an exception whichthe SEH handles, looks up the location in its database and runs the correct code to continue on.

In the terms of debuggers how do you think it breaks on certain parts of code? it's not magic...no, it sets a int 3 on the address, which throws an exception when ran, that the debuggers auto handles and allows you to pause the program flow and see what's in registers etc...

and you're missing the point of all this, ideally he should just check the size of the buffer, sure, but what if a buffer accidently isn't given, and instead a integar is? CRASH! this is unacceptable in vital programs running at system level such as services or programs that need to continue to run. His code could be incorporated in such a scenario is my point. Also it's not just about size, to give the example of wsprintf, if you have countless %s and very few string inputs, there's a crash right there which can run shellcode and all that non-sense, they did it with ollydbg.

[jj2007]

If your code is *expecting* an exception, there is something wrong.
...
Rare events are not part of normal flow control.

Normally I would strongly agree - but what if the "good" checks cost so much more time than letting it crash, in a controlled way, into an "exception"? Guard pages do that all the time - have a look at the page faults column in Task Manager...

But I agree that, beyond ideology, you need a damn good justification to use SEH that way. By the way, has anybody looked at this example where good ol' lstrcpy fails clamorously?

[sinsi]

By the way, has anybody looked at this example where good ol' lstrcpy fails clamorously?

To be fair, the docs say (now, maybe not before?)

Using this function incorrectly can compromise the security of your application. This function uses structured exception handling (SEH) to catch access violations and other errors. When this function catches SEH errors, it returns NULL without null-terminating the string and without notifying the caller of the error. The caller is not safe to assume that insufficient space is the error condition.

[ecube]

If your code is *expecting* an exception, there is something wrong.
...
Rare events are not part of normal flow control.

Normally I would strongly agree - but what if the "good" checks cost so much more time than letting it crash, in a controlled way, into an "exception"? Guard pages do that all the time - have a look at the page faults column in Task Manager...

But I agree that, beyond ideology, you need a damn good justification to use SEH that way. By the way, has anybody looked at this example where good ol' lstrcpy fails clamorously?

i've already explained why, if your program is of any importance as far as it running or being safe then SEH is required, otherwise you just contribute to the countless "exploits" skiddies discover in badly written software, which leaves users more open to attackers and makes windows look worse. Any kind of server software, any kind of service, or similar.Computers are getting so fast now that a few more clocks to handle SEH isn't detrimental like back in the day.

[jj2007]

By the way, has anybody looked at this example where good ol' lstrcpy fails clamorously?

To be fair, the docs say (now, maybe not before?)

Using this function incorrectly can compromise the security of your application. This function uses structured exception handling (SEH) to catch access violations and other errors. When this function catches SEH errors, it returns NULL without null-terminating the string and without notifying the caller of the error. The caller is not safe to assume that insufficient space is the error condition.

Interesting: So they know it. On the other hand, it supports the "let it crash" line. Do you have an error check after each lstrcpy or lstrcat? I have 226 occurrencies of lstrc*** in the RichMasm source, none has an error check. So their SEH is a safe recipe for an unchaseable bug that occurs in very rare circumstances - the chance is about 1:4096. Fortunately most if not all of these lstrc*** deal with short messages well below the size of a page, but imagine you use it for file handling on a huge number of files? And we are not talking about a hobby coder's algo here - lstrcpy is part of the OS, and it crashes silently because they decided to "handle" the exception ::)

[ecube]

well instead of using lstrcpy you can rename to lstrcpyx for all instances and just have it be your own function with SEH that trys to call lstrcpy ;D 2 second fix. But yeah hobby coder or the code being used in a program that has no importance, SEH isn't needed. SEH is also nice in debugging because you log to a textfile the registers contents, the params passed when it crashed and ofcourse what function.

[sinsi]

Well, it is a function, which returns a value, so some error-checking would be in order...
Does anyone check the return values of RegisterClassEx/CreateWindowEx? Only when your code doesn't show a window I'll bet, then you get rid of the check.

Return values are there for a reason, and how bad is it to branch after a "test eax,eax" anyway?
Then we can get one of those "unexpected error" or "internal error" message boxes  :bdg