Is it a bug in a popular miner that lowers a chance to find a nonce? [SOLVED]

[Come-from-Beyond]

Hello.
Few days ago i was digging through the source of ArtForz' miner (https://github.com/ArtForz/cpuminer) and had found a piece of code that looked weird. It's in the very end of "scrypt.c":

Code:

uint32_t Htarg = ((const uint32_t *)ptarget)[7];
...
...
...
if (tmp_hash7 <= Htarg) {
	((uint32_t *)pdata)[19] = byteswap(n);
	*hashes_done = n;
	return true;
}

With current LTC difficulty ptarget points to "0000000000000000000000000000000000000000000000000000a78e01000000" number. Which becomes 0x000000018ea70000.......... after conversion. So Htarg contains 0x00000001 and we are trying to find a nonce comparing last 4 bytes to 0x00000001. I suspect that we should pay attention to the next 4 bytes which are 0x8ea70000 and compare 64-bit Htarg (not 32!) to 0x000000018ea70000. This will increase our chance to "win" a block, because then we need to hit [0-0x000000018ea70000] not [0-0x0000000100000000] interval.

Am I right?

PS: If you mine in a pool you get work (share) with much lower difficulty (higher target), so you don't loose 30% chance to find a solution, loss is like 0.01%. But if you prefer solo-mining then you could get +50% more coins for the same period of time. In case if I'm not mistaken, of course...

[2112]

Looks like with the "less than or equal" comparison the interval (in your notation) is
[0-0x00000001FFFFFFFF]. In my notation it would be [0-0x00000001XXXXXXXX], where X stands for "don't care". Please check the data flow again.

[Come-from-Beyond]

You are right. I didn't notice "=". That explains why sometimes my miner writes that proof-of-work failed.