2009/10/29 Nick Treleaven <[email protected]>: > On Thu, 29 Oct 2009 08:56:42 +1100 > Lex Trotman <[email protected]> wrote: > >> >> > Not breaking the ABI is a goal of any future plugin API extensions, so >> >> > we don't have to rebuild all plugins so often. >> >> >> >> Excellent goal. >> >> >> >> In which case you might need to add that plugins should not save and >> >> restore structures since they may miss fields added later or fail to >> >> comply with changes to structure invariants required (neither of which >> >> will trigger an ABI/API step according to the doc). >> > >> > Not sure if I'm with you. Doesn't this cover it: >> > * Don't let plugins allocate any structs (stack or heap). >> >> I was actually thinking about a plugin that tried to save and restore >> structure contents so it could restore values after running or save >> them to file for restore next time. The struct might be allocated >> prior to the plugin being loaded. > > I think plugins shouldn't try to do that. If it was necessary, we could > add functions to the API for any structures that need to be synced > from/to disk.
Thats what I was saying, this should be on the list separate to allocate :-) > >> > What do you mean by structure invariants? >> >> Required relationships between members of structures, for example if >> GeanyBuildCommand has a non-null label it might reasonably require a >> non-null command and working directory to save checking all the time. >> (Note actually I think I test all of them all the time but its an >> example :-) >> >> The API functions I provided all checked parameters then called >> internal versions that didn't. > > Basically plugins probably shouldn't really set any of the exposed > struct fields, only read them. Maybe we should mark them as const but > I'm not sure if this would cause issues. Yes if all the API functions returned const pointers. That doesn't stop some conniving plugin writer from casting them non-const but that is deliberate rather than accidental misuse so bugs are firmly the plugin writers problem. > > Anyway, we could improve the API docs (doxygen) to warn about these > things. (The HACKING file is for working on Geany's core). Or maybe both so there's a chance it will be seen, remember we're talking about programmers reading the manual :-) Cheers Lex > > Regards, > Nick > _______________________________________________ > Geany-devel mailing list > [email protected] > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > _______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
