On Wed, Apr 26, 2006 at 12:54:43PM +0100, tom christie wrote: > It's really just an extra layer of protection... > I realise that the binary and data files will be accessed as a single unit, > but a corrupt data file should never cause a segfault.
That's somewhat like saying a corrupt binary should never cause a segfault... if the data file gets corrupted in a way that breaks the syntax, then there wont be enouhg data for hte host to attempt to load the plugin and it will refuse, but if through some miracle ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of crazy shit will go down. > Without a built-in struct version identifier the host (or LADSPA library) > may segfault by incorrectly accessing the struct. (if the data file is > corrupt) I'm not interested in the case the data file is corrupt, its too much of a special case, and theres nothing sensible you can do about it. No-ones seriously interested in guarding against the caes where the .so is corrupt. If you care that much, ship a sha1 checksum with your plugin. > With a built-in struct version identifier the host (or LADSPA library) > can ensure it will never access the struct in a way which will cause a > segfault. > (even if the data file is corrupt.) No it can't :) If the data file is currupt in any plausible way the host wont have enough information to even attept to open the plugin anyway. - Steve
