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