26 Apr
2006
26 Apr
'06
9:54 a.m.
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.
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)
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.)
Okay, I'll hold my peace now ;)
On 4/26/06, Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> wrote:
On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie
wrote:
...
Well, it provides a _built-in_ way of ensuring
that the struct is
properly accessed,
even if the metadata file is corrupted or lost.
Say a user meddles with the metadata file to make a 2.0 plugin look
like a 2.1 plugin. The host attempts to access 2.1 functionality and
core dumps.
Say the metadata file has been lost - the plugin contains sufficient
information to remain accessible although it no longer has any
associated metadata.
It's not metadata. If the data is corrupt or missing then youre SOL. It's
just as vital as the arrays of structs were in LADSPA 1; if you dont have
the data theres no way to use the plugin without causing segfaults.
This is why the "plugin" is really a directory, all the stuff in there is
neccesary.
- Steve