On Tue, Oct 14, 2014 at 7:56 AM, Florian Zumbiehl <fl...@florz.de> wrote:
> Hi, > > > > Take JSON as an example: JSON character strings can encode NULs, so if > > > CHICKEN were to reject NULs in character strings, you could not write a > > > JSON parser in CHICKEN. > > > > That's technically true, but where will you find a JSON document in the > > wild that contains "\u0000"? JSON parsers written in C won't be able to > > handle it either, since AFAIK they all return C strings. You probably > > won't be able to store it in a database either, since they use C APIs > > somewhere in the process. > > If some code can't handle that, it's by definition not a JSON parser. > JSON is an interesting example since it started out as a potential security issue because it was proposed before parsers existed, and there was a tendency to just use Eval to parse. Maybe not the best place to look for safe coding practices. Note XML, which is the usual transport for JSON, doesn't allow NUL, or in fact any ASCII control characters, so I think you're going to have a difficult time supporting such JSON anyway. But If you really do want this feature you're still welcome to support it in a JSON parser - we have u8vectors for binary data. In general there are many examples of formats that mix textual and binary data. If you conflate these types in your own language then you do get some small parsing convenience (and perhaps more difficulty writing secure programs). In portable Scheme we don't mix these types. I'm not sure I understand the find -print0 example, which is just another binary format which forbids embedded NULs in strings. -- Alex
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers