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 <[EMAIL PROTECTED]> 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 >
