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

Reply via email to