Re: [Chicken-hackers] CHICKEN in production

[Florian Zumbiehl]

Hi,

> 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.

I don't really get what your point is here?!

> 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

JSON transport over XML? Well, certainly possible, I doubt it's (still?)
the usual way, but that seems besides the point anyway, as I don't see why
it shouldn't be possible to transport NULs in JSON strings through XML?!
"["\u0000"]" seems to me like perfectly valid XML PCDATA
representing a perfectly valid JSON document containing a perfectly valid
character string.

> do want this feature you're still welcome to support it in a JSON parser -
> we have u8vectors for binary data.

I think that's what I wrote two posts ago? Yes, of course, you can work
around such limitations, but you certainly are not suggesting that the
right way to implement a JSON parser is to by default return character
strings as u8vectors, are you? JSON can't do "binary data", all it does is
character strings (and numbers, and booleans, ...).

> 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 don't mix any types, I am talking about NUL characters, which are, as the
name suggests, characters, and have nothing to do with "binary data".

Florian