On Fri, Aug 4, 2017 at 8:11 AM, Nico Williams <n...@cryptonector.com> wrote:
> On Fri, Aug 04, 2017 at 10:17:33AM +0200, Dominique Devienne wrote: > > On Fri, Aug 4, 2017 at 2:46 AM, Nico Williams <n...@cryptonector.com> > wrote: > > > You're mistaken. > > > > > > lib<name>.so is NOT "the default naming scheme on many *nix platforms". > > > > > > lib<name>.so is the naming scheme when you want the link-editor (e.g., > > > ld(1)) to find a library using -l<name>. > > > > > > But loadable modules are almost never meant to be used that way. > > > They're usually meant to be used only through dlopen() and friends. > > > > While you're technically correct, Matt's request seems completely > > reasonable to me. > > Not if it's a result of being mistaken. Now that OP knows about object > naming, he can reconsider and restate his request. > > > If SQLite wasn't doing *any* changes to the filename, not adding the > > extension for example, you may have had a point, but since it does, > > trying with the lib prefix on Linux, which is undeniably a common > > No, see, the ".so"/".dll" suffix is used in all cases, and it varies by > platform, so it's best if SQLite3 adds it so you can keep your code more > portable. While the "lib" prefix is only ever needed if you want a > link-edit to find the thing as -l<name> -- which you almost never ever > want when <name> is a loadable module. > so does the lib prefix. You cannot package a <name>.so in an android .apk. but you can include lib<name>.so. > > > naming convention on Linux, seems like a worthwhile addition. [...] > > You didn't understand. > At which point, because I apparently missed that too. if one is using CMake, you get a lib<target>.so without setting additional options. > > > I really don't see what's controversial with Matt's request :) > > a) it's borne of a mistake > b) it's not necessary > c) it's more code and more docs > d) it's more likely to lead to accidents > > a) It's born of 'I want to load 'myExtension'" and sqlite already does substitutions. b) maybe. c) so? it's not like a whole path is specified that you'd get /usr/lib/myextension and then try lib/usr/lib/myextension.so d) and more likely to cause scripting configuration issues; There's no .if or .goto commands to be able to handle error conditions. So you have to maintain at least 2 scripts instead of just 1. Leading to more accidents in updating one and not the other. > > It's not like load-extension is a performance-critical operation, that > > trying an extra load is that expensive. > > This is true, but also irrelevant :) > > > And the security consideration that an "attacker" could make it load > > his own library instead, but using a different name tried before the > > actual one is moot IMHO, since extension loading is by nature unsafe. > > > > In short, I support Matt's request and I hope DRH considers it seriously. > > FWIW :). --DD > > What problems does this solve? None. > > Wrong, it adds the ability to code a single script to execute. > Nico > -- > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
