Richard. Were you aware of this paper? http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf
Are you able to put two facts together? What prevents stack busting or other code injection attacks on an otherwise valid pseudo-null pointer by simply decoding the address space and observing where strcmp() loads a register to one of the pointer "keys" you've insisted be conveniently published for hackers in the data segment? On Tue, Jul 25, 2017 at 10:43 AM, Richard Hipp <d...@sqlite.org> wrote: > On 7/24/17, petern <peter.nichvolo...@gmail.com> wrote: > > Great. But, if this is an ultimate replacement for BLOB'ed pointers, > these > > new pseudo-null pointers must support SQLITE_STATIC and destructor > function > > pointer lifetime disposition for those migrating their code. > > Nobody is forcing you to migrate your legacy code to the new API. > Anything that worked for you in 3.19.3 (or earlier) will continue to > work just as well in 3.20.0. If what you are doing now works for you, > then you are welcomed to keep doing exactly the same in the future. > > > > > Why can't the producer destructor disposition be preserved within a chain > > of application functions by subsequent consumers passing SQLITE_STATIC > > disposition as they do now? > > I cannot say with precision because your proposal is vague. But what > you want to do will very likely use extra memory and extra CPU cycles > for the overwhelmingly common case where pointers are not being > passed. We do not want to burden the common case for the convenience > of an outlier. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > 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
