> > > > Clean room/disassemble magic code is different. Inside functions there is magic code performing operations with no logical reason > > or data supporting it. This code would normally appear and function correctly without any development process. Ie not natural. > > Code normally never just works perfectly normally need to be edited and corrected. It has finger prints. Lack of mistakes > > requiring reversions and corrections is a clear warning sign to Clean room or disassemble being used. > > > The above is not necessarily true. Some functions, like the one that I'm working on, will not be accepted if it contains errors. However, if your code 'duplicates' the functioning of other code, then you are not black-boxing or you just happened to hit on the exact same code. The first means that your creditability is gone, the second means someone has to 'fix' your code so that it functions in a different manner. Something like moving the case selections in a switch statement or removing code that is not needed. The basic rules are true. Look back at your patches in the processes of development you have put up ideas how to solve problems and so on. Even at times tried different paths. Exactly why would you be bothering trying different paths if you know what is inside. Reversed/clean room source code normally lacks the normal processes of code creation. Would it not be normal for you to put forward patches that get rejected due to over looking something along the way of getting to accepted. Basically there is a natural process to code development. Coder will miss stuff will have to go back and correct stuff. The give away is the lack of that process being required for functionality. There is more than one way of documenting you are forgetting about the commit comments. This is still documentation about the code to be correct for detecting reversing the commit data is more useful. Did this function come to life fully functional or did it need alterations to make it work right. You can see alterations to make the code work right in a progressive way some times the alterations will be helpful sometimes they will cause other bugs this is natural. Once you have a set of progressive alterations it not magic code. Progressive alterations says that it happen in the natural way code does. Yes common mistake when I say documentation people think in source code docs not history and comments on the code that are stored in a independent archive. This also tracks who submitted what this is also handy to work out if anyone is breaking the rules. I should have been more correct with clean room it magic code that is functionally correct without a development process to get there. Probability of doing that once without clean room or reversing is insanely rare. Doing it twice is almost to the point of impossible. Black box it also insanely rare to funny test a function first time and find all bugs and quirks of a function. Another thing that gives people who have reversed or clean roomed away if they try building black box test cases after the fact breach of natural process. Also helps that lot of windows functions have very odd bugs that have to be detected. Lot of code for wine at first does not contain this odd bugs. Ie reversed code would. There are signatures all threw wine code history pointing to the fact it black box code. Non black box would not have the same history.
