26 Apr
2006
26 Apr
'06
12:56 p.m.
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