Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2005
Offline Last Active Today, 01:53 PM

Posts I've Made

In Topic: SEH: corrupt program state when catching access violation

13 November 2014 - 06:52 PM

Well... That took less than 20 seconds. I can't believe my exception breaks simply weren't properly set up in the IDE. Now I feel really stupid...

In Topic: SEH: corrupt program state when catching access violation

13 November 2014 - 06:40 PM

SEH on 32-bit programs does not respect C++ stack unwinding semantics. It is highly inadvisable to try and mix C++ object lifetime management with SEH stack unwinding. SEH stack unwinds may appear to corrupt call stacks, will screw with your RAII code, and will probably generally make things worse instead of better.

If you genuinely need SEH to snag hardware traps, you need to put the __try/__except block as close to the faulting location as possible, i.e. the exact opposite of the way you're doing it.


Hm - can you elaborate on what I should take away from this:


1) would compiling to 64 bits alleviate or resolve the issue?

2) is there an alternative to SEH to trap hardware faults? (as far as I know there isn't on Windows)

3) since I don't know where to set up my handler when trying to locate the source of the fault in the first place, SEH is pretty much useless and I should just be prepared to do what I've been doing so far - manually step though code until I can reason where the fault can originate from

In Topic: SEH: corrupt program state when catching access violation

13 November 2014 - 06:21 PM

32-bit build on a 64-bit hardware and OS. Windows 8.1.

In Topic: A little brain teaser

10 November 2014 - 12:13 PM

I guess you wouldn't consider a union of an uint64_t and two uint32_ts either as anonymous struct or array (and no explicit shifts or bitwise operations at all) a valid solution?


To be honest I started this thread for fun because I had to go through 3 or 4 different solutions before I found one that didn't generate an error. Under those restrictions it just felt like a fun exercise, so I only wrote down the ones I had to work around. Like I stated in my original post, I only started this thread to see if there were other solutions that I didn't think about :).

In Topic: A little brain teaser

10 November 2014 - 11:35 AM


So, to recap, given the 64-bit sample value "515396075660", extract the low and and high dwords using a combination of only RSH (>>) and any non-bitwise operators.

Non-bitwise permitting +, -, *, /, and % ?


high = val / 4294967296; // or high = val >> 32; if having one right-shift is a requirement

low = val % 4294967296;


// low = 140, high = 120


I feel like I'm missing something.



My bad - I neglected to mention natvis didn't accept modulo.



4294967296 = 1 << 32, not (1 << 32) + 1. You've basically emulated a variant of the operation "modulo 2^32", which is the same as masking all but the lowest 32 bits. I doubt it can be done with less than three different non-bitwise operators except for SHR, though. But, thinking outside the box, cast the 64-bit integer to a structure of two 32-bit integers? That may be cheating though. Another option: convert your 64-bit integer to a 16-character hexadecimal string, and cut it in half? You never said the output needed to be in integer format smile.png


Well - for the sake of the argument it doesn't matter, although for natvis it needs to be a resolvable expression that produces a valid numeric or regular string output :)@the typo - indeed, I blindly copied from the Windows Calculator, which treats all values as signed, meaning the number was off by one.


Can you do a left shift by using a negative value as right shift amount?


Hm - that's an interesting idea. I'll try it out when I get the chance.