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-
