Dominique. strcmp alone won't care if zPType is code segment or data
segment. As is, this release won't need the dynamic linker to perfectly
consolidate constants. Much ado. [You are also free to clone three very
tiny API functions substituting integer/etc PType if you're in the mood to
ship a custom build to your customers.]
SQLITE_API void *sqlite3_value_pointer(sqlite3_value *pVal, const char
*zPType){
Mem *p = (Mem*)pVal;
if( (p->flags&(MEM_TypeMask|MEM_Term|MEM_Subtype)) ==
(MEM_Null|MEM_Term|MEM_Subtype)
&& zPType!=0
&& p->eSubtype=='p'
&& strcmp(p->u.zPType, zPType)==0
){
return (void*)p->z;
}else{
return 0;
}
}
On Fri, Aug 4, 2017 at 6:37 AM, Dominique Devienne <ddevie...@gmail.com>
wrote:
> On Fri, Aug 4, 2017 at 11:37 AM, Ulrich Telle <ulrich.te...@gmx.de> wrote:
>
> > Regarding the development of SQLite extensions (UDFs) and using the
> > pointer-binding interface to communicate between different extensions
>
> (AFAIK one of the reasons to introduce the new pointer-binding interface)
> > the advice to use string literals is certainly good.
> >
>
> I think on the contrary they are more meant to communicate across different
> UDFs of the *same* extension, and not across extensions.
>
> Typical use (IMHO) of the pointer-binding interface is to pass around a
> pointer to an extension-defined struct from one function to another,
> from an inner "parsing" function (e.g. taking JSON text and parsing it into
> a compact and efficient binary representation) whose result is
> used by another UDF of the same extension that is aware of the custom
> struct of the "parsed representation" of the JSON and can therefore
> do more efficient processing. In that context, pointer equality of string
> literals can be used and relied upon w/o even a strcmp(), and both
> UTFs are "tightly coupled". The "type-pointer" is simply a "poor man's type
> system" to guarantee the hard-cast in the receiving UDF is "safe".
>
> I'm not even sure you can guarantee uniqueness of string literals across
> dynamically loaded shared libraries, maybe the runtime linker
> merges equivalent read-only "static" text from different libs, but that
> seems very platform-dependent and not something to rely on.
>
> It's also probably unusual IMHO for different extensions to share headers
> to have a common understanding of a custom struct
> to share at runtime via SQLite pointer-binding in UDFs across these
> extensions. Not impossible, but seem rather unlikely to me.
>
> When you look at it from this lens, then enforcing string literals for the
> type-pointer makes sense. My $0.02, FWIW. --DD
>
> PS: Yes, like others I'd love it if DRH went further into this "custom
> type" route, even persistent ones longer term with a format change,
> since pointer-binding with type-string-pointer is going in that
> direction, at least at runtime-only, and only for "temporaries" across
> UDFs,
> but I'm afraid we're a long way from that, and I'm not holding my breadth
> :)
> _______________________________________________
> 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
