Dave. The documentation contains many such catch-all statements which do
not reflect a full decision tree. The usual cover story will either be (I
paraphrase) : 1. "that's an implementation detail" or 2. "it might change
later, so the documentation can only make a short blanket statement".
It is far more likely that spelling and grammatical errors you report of
the documentation will be corrected.
The current decision tree of the particular catch-all documentation comment
you found is in vdbemem.c at the comment and function body listing below.
Ultimately there is only the source code. Getting used to reading it for
yourself will probably save you a lot of time.
int sqlite3ValueBytes(sqlite3_value *pVal, u8 enc){
Mem *p = (Mem*)pVal;
assert( (p->flags & MEM_Null)==0 || (p->flags & (MEM_Str|MEM_Blob))==0 );
if( (p->flags & MEM_Str)!=0 && pVal->enc==enc ){
return p->n;
}
if( (p->flags & MEM_Blob)!=0 ){
if( p->flags & MEM_Zero ){
return p->n + p->u.nZero;
}else{
return p->n;
}
}
if( p->flags & MEM_Null ) return 0;
return valueBytes(pVal, enc);
}
Peter
On Wed, Dec 13, 2017 at 8:38 AM, dave <[email protected]> wrote:
> I have a question regarding the API documention at
> http://sqlite.org/c3ref/value_blob.html, which states:
> "... the pointer returned from sqlite3_value_blob(), .. can be invalidated
> by a subsequent call to sqlite3_value_bytes(), ..."
> Is that statement still true? I ask because I notice that the source of
> many of the extensions in 'sqlite/ext' seem to violate that advice.
>
> I first noticed this when I was recently working on fileio.c (e.g. line 73
> vs 77), but grepping through the source I find many other cases where the
> pointer is retrieved via *_blob() or *.text() BEFORE invoking
> sqlite3_value_bytes(). E.g these source and line numbers:
> fts2_tokenizer.c:71, 72
> fts3_expr.c:1248, 1249
> fts3_tokenizer.c:78, 79
> fts3_tokenize_vtab.c:347, 348
> fts3_write.c:5290, 5291
> fts5_index.c:6270, 6271
> fts5_storage.c:735, 736
> fts5_tcl.c:547
> fts5_test_tok.c:375, 376
> fts5_vocab.c:607, 608; 612, 613; 616, 617
> (I stopped grepping at this point; this list is not comprehensive).
>
> Anyway, just wondered if the api documentation's advice is maybe
> out-of-date
> with current reality. Thoughts/comments?
>
> Cheers!
> -dave
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
