Is F4I in violation of the LGPL? - Part III
 sp <foo bar com> |
Wednesday, November 16 2005 15:43.18 CST |
"Frank" posted the following comment to my last update.
"What does this code fragment do? It accesses data that is well-defined by an open specification. There is little leeway for a software developer to do things differently. So far, this may be coincidence, or a case of developers being "inspired" by looking at other source code -- like the famous "stolen" Unix code fragments in Linux. This is an invitation for more research, yes, but I dont see a smoking gun just yet."
This is a valid concern and I wanted to address this anyway, so lets do it right here. I think its important enough to write a new update instead of just replying to Frank.
Ive produced a complete annotated disassembly of the function in question. It matches the function from the LAME code 99%. I say 99% because there are differences which can be reasonably explained by common compiler optimization techniques. Ive mentioned these techniques in the annotated disassembly where appropriate.
If the 99%/100% match of a 90 lines C function is a coincidence it goes beyond what Im capable to detect using my tools.
Click here for the LAME source code.
.
.
.
Click here for the annotated disassembly.
.
.
.
Edit: I want to ask the people familiar with the LAME function in question something. Look at the following four lines from the LAME source code:
if( buf[0] != VBRTag[0] && buf[0] != VBRTag2[0] ) return 0; / fail /
if( buf[1] != VBRTag[1] && buf[1] != VBRTag2[1]) return 0; /* header not found*/
if( buf[2] != VBRTag[2] && buf[2] != VBRTag2[2]) return 0;
if( buf[3] != VBRTag[3] && buf[3] != VBRTag2[3]) return 0;
This piece of code attempts to check if buf contains Xing or Info. I dont know about the underlying data structures but the way it checks looks wrong to me. This piece of code passes if buf is a combination of Xing and Info, like Iing or Xnfo which is probably not the desired functionality. Can anybody confirm that this is a bug or is not a bug? Because if its a bug its also part of the F4I code. This would solidify the assumption that the code was stolen from LAME even more.
Edit: OK guys, Im going to proclaim victory now as Ive found undeniable proof that this match is not a coincidence. I just took the the functions GetVbrTag and ExtractI4 from the LAME code and compiled them myself using the freely available Visual C++ 2003 commandline tools. The only compiler parameter I used is /Ox to turn on maximum optimizations. The resulting code is byte for byte the code from the F4I OCX file. Including all my correctly predicted compiler optimizations (function inlining, if-clause merging, operation re-ordering, ...).
Click here to see the disassembly of my own compiled version of the LAME code. It matches the disassembly posted earlier perfectly. Note that I didnt bother to re-name variables or to insert comments.
Comments
| Posted: Wednesday, December 31 1969 18:00.00 CST | |