On Thu, Apr 19, 2018 at 3:37 PM, J Decker <d3c...@gmail.com> wrote: > > > On Thu, Apr 19, 2018 at 3:22 PM, Keith Medcalf <kmedc...@dessus.com> > wrote: > >> >> Actually, nothing in the C or C++ world will "go past" the NULL byte >> since the very definition of a C string is a "bunch-o-bytes that are >> non-zero followed by one that is". >> >> And sory for the double response; but if C/C++ couldn't handle a NUL character (the character is 1 L) then spidermonkey/chakra/V8 would have problems with NUL characters in javascript strings. But it doesn't. Why is that?
> that doesnt' mean you can use a custom token structure that contains both > the pointer and length of the data. (which it already has) > sure, using standard C api - strlen, etc sure... but sqlite uses a custom > function internally sqlite3stlren30 which can easily be extended to take > the length of the string; but wait, if it was saved, it wouldn't need to be > called, and a overall performance gain is created. > > the biggest problem is really the internal function '(something)printf' > which returns a char *, and has no space to return the length, like > snprintf would. > > and I can easily put nuls into a string.... > > char buf[256]; > int len = snprintf( buf, 256, "put a nul %c here and here %c", 0, 0 ); > and the length returned would be 27. > > >> If you want to embed non UTF8 text you should be using a BLOB not TEXT. >> Text means "an array of non-zero characters terminated by a zero byte" and >> a BLOB means a "bag-o-bytes" of a specific size. >> >> Blob means binary; havihng to deal with a binary structure to convert to > a string and back is ridiculous when the interface already supports storing > and getting strings with \0 in them. > > >> Things meants to work on C "strings" should always stop at the zero >> terminator. Failure to do so can lead to AHBL. >> >> > So don't use the standard library. That was one of the first htings I > created for my MUD client; a smart text string class. (I say class in the > generic term, not the literal, since it was written in C) > > >> (Note, this applies to "wide" (as in word) and "fat" (as in double word) >> and obese (as in quad word) strings as well. They are a sequence of >> words/double-words/quad-words/ten-words (whatever) that are non-zero >> followed by one that is zero -- and the narrow/wide/fat/obese string ends >> at the zeo value). >> >> > utf8everywhere.org > No reason to use wide char. > > > get good, son. (sorry if that's overly offensive) > > --- >> The fact that there's a Highway to Hell but only a Stairway to Heaven >> says a lot about anticipated traffic volume. >> > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users