[linux-audio-dev] LADSPA 2

[Dave Robillard]

On Wed, 2006-04-26 at 17:55 +0100, Steve Harris wrote:
> On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote:
> > > That's somewhat like saying a corrupt binary
> > > should never cause a segfault...
> > No, not at all.
> > The data file is accessed as an input stream (to the host / LADSPA library).
> > It's fine for a bad data file to cause the library to fail to be able
> > to load it, or to load it and produce unexpected output, but it should
> > *never* cause it to segfault.
> 
> the only situation it can cause a segfault is where its mangled in a
> somehow still structurally and syntaxically correct way (too unlikly to be
> worth considering) or if the host pushes on without enough information.
> 
> The point I was making is that you will get segfaults if you try to us the
> struct without the data, even if you know the version number, so dont.
>  
> > All I'm saying is that if the discovery function may potentially
> > return differing structs from one LADSPA version to another, then it
> > ought also provide a mechanism of determining exactly which struct it
> > is returning.
> 
> Sure, but its easier to version the struct in the data.

Thinking about this I was worried about parallel installed multiple
versions of the same plugin, but as long as the URI refers to a
compatible version of the plugin, we don't need versioning in the struct
itself, since the URI between two versions of a plugin (one of which is
LADSPA2.0 and one which is binary incompatible LADSPA2.2 or whatever)
must change since it's incompatible, right?

We need to make absolutely sure multiple versions of a plugin can be
installed at once, including new incompatible versions of the spec, is
my point.  I /think/ it's okay as stands though.

-DR-