[linux-audio-dev] LADSPA 2

Steve Harris S.W.Harris at ecs.soton.ac.uk
Wed Apr 26 14:56:28 UTC 2006


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



More information about the Linux-audio-dev mailing list