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@email-addr-hidden> 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
>
Received on Thu Apr 27 00:15:10 2006
This archive was generated by hypermail 2.1.8 : Thu Apr 27 2006 - 00:15:11 EEST