Sean O'Rourke wrote: > On Sat, 21 Sep 2002, Leopold Toetsch wrote: > > >>As PBC files might be built from different core.ops aka core_ops.c, it >>is necessary to add a fingerprint to PBC files, to validate, that the >>interpreter uses the very same ops, when running the PBC. >> >>- during "make" a fingerprint of core_ops.c is generated: >>$ perl -pe's/\s//g' < core_ops.c | md5sum | cut -f1 -d' ' [1] >>305c25a0a3fe675f7fdc5d323020eae2 >> > > I think we could do better than checksumming the whole file, since that > will pick up changes in comments, etc. What we really want to know is > whether or not the opcode numbers have changed, and I think two things > will handle this sufficiently: > > - a parrot version number in the bytecode file; and > - developers remembering not to run old pbc files when adding core ops
I did think on this quite a long time, there is no perfect solution. - The parrot version number (0.0.8) is not enough, or might be different, albeit core.ops is the same. If you think of a changing version number, when core.ops is changed, yes theoretically, this can work, _if_ any change to core.ops (or build helpers) changes the version number too. - A checksum over the whole file might be overkill, but normally, when comments got changed, there where some changes in the engine too, if necessary, we could strip comments (as I proposed to s/\s//g) too. I prefer a superfluous build run for a PBC over running a br0ken one. - A bare minimum check would be: the number of opcodes is the same. - This fingerprinting is not intended for developers only. And "developers remembering" ... no bear with me, 44y+5d ;-) - Currently this is not a big problem (though I did ran old PBC files with a patched core, which segfaulted or so, an hour later I knew why) So especially for developers, it would be a time safer, to put this in early, IMHO. That we need it finally, I think, there is no doubt. > /s leo
