Actually, code can also lie with all he optimization the compilers do nowaydays. So: comments lie, code sometimes lie, disassembly never lies.
Re:These are a few of my favorite (Microsoft) bugs
on
Pet Bugs?
·
· Score: 1
You're FindFirstFile()/FindNextFile() bug in Windows NT is no bug. You say that fNextFile || dwLastError!=ERROR_NO_MORE_FILES is a problem because the for loop only terminates when fNextFile is FALSE AND dwLastError equals ERROR_NO_MORE_FILES, but since when is || a boolean AND? That's a boolean OR. So the loop stops if fNextFile is FALSE OR dwLastError equals ERROR_NO_MORE_FILES. The function isn't buggy.
Actually, code can also lie with all he optimization the compilers do nowaydays.
So: comments lie, code sometimes lie, disassembly never lies.
You're FindFirstFile()/FindNextFile() bug in Windows NT is no bug. You say that fNextFile || dwLastError!=ERROR_NO_MORE_FILES is a problem because the for loop only terminates when fNextFile is FALSE AND dwLastError equals ERROR_NO_MORE_FILES, but since when is || a boolean AND? That's a boolean OR. So the loop stops if fNextFile is FALSE OR dwLastError equals ERROR_NO_MORE_FILES. The function isn't buggy.
Indy meets The Mummy
Indy 4: Raiders of the lost, then found and lost again, Ark
Well, If you run it on an old Pentium box it will work. Then: it will become 111, which is 666 if you multiply it by 6