3 ms·
> Oh no please don't. Don't what? The author isn't telling people to put NUL characters in their data; they're telling Postgres not to abort in the presence of
by chriswarbo 6y ago
> Oh no please don't.
Don't what? The author isn't telling people to put NUL characters in their data; they're telling Postgres not to abort in the presence of a NUL character.
The main job of a database is to store and retrieve data. Erroring-out for valid UTF-8 strings can itself "wreak all kinds of havoc on applications", since it may be unexpected behaviour.
Personally, my expectation would be for a unicode string type to store any unicode string; and for data to be retrieved without modification. I would expect the same for any "generic plumbing" technology, whether it's a database, a programming language, a file system, a data processing command or API, etc.
As a side note, I tend to use property-based testing, which is especially good at ensuring NUL characters are handled correctly (property-based testing uses randomly generated inputs, starting with "small" values, and "shrinking" counterexamples; NUL is considered the "smallest" character, so it appears quite often).
- corty 6y agoThe database throwing an exception can be unexpected, but is usually safe in that it usually doesn't create a lot of exploit opportunities. Allowing null bytes in strings is far worse, it is well known to be exploitable in numerous situations and historically has been. For example lots of ASN.1 and X.509 certificate exploits have been caused by allowing null bytes in strings there.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- abhinavshaha 6y agohttps://www.etechnoblogs.com/entertainment/thewatchseries-to-alternatives https://www.etechnoblogs.com/entertainment/thewatchseries-to...
- abhinavshaha 6y agohttps://www.etechnoblogs.com/sports/vipbox-best-alternatives https://www.etechnoblogs.com/sports/vipbox-best-alternatives
- SAI_Peregrinus 6y agoThose issues aren't generally actually due to NULL bytes in strings, but rather due to treating UTF-8 strings as C `char*` (or other mistreatment of "compatible" encodings). C code cannot handle UTF-8 strings as `char*`, even if you've got a UTF-8 locale (eg `LANG=en_US.UTF-8`). You have to convert multibyte strings to wide character strings (eg using `mbrtowc` to get a `wchar_t*` and then operate on that. C has multiple string types, no good type safety for them, and confusing them leads to vulnerabilities.