On Wed, Oct 8, 2014 at 5:54 PM, John Cowan co...@mercury.ccil.org wrote:
Peter Bex scripsit:
It was discussed before on this list, and I shot it down due to
the danger, however I think it may be possible to change the string
representation to always include a \0 at the end, so that passing it
On Mon, Oct 13, 2014 at 2:39 PM, Peter Bex peter@xs4all.nl wrote:
On Mon, Oct 13, 2014 at 02:35:54PM +0200, Michele La Monaca wrote:
I must confess I didn't read the entire thread. But, what exactly buys
us barring NUL in strings other than limiting the usefulness of the
type and its
On Mon, Oct 13, 2014 at 04:22:57PM +0200, Michele La Monaca wrote:
On Mon, Oct 13, 2014 at 2:39 PM, Peter Bex peter@xs4all.nl wrote:
Good one. Anyway, I find that perpetuating C limitations/missteps in
higher level languages just because we can't be sure to handle
interactions safely,
Hi,
The danger could be avoided by a taint bit: if the string is known
to not contain \0, it can be passed directly. Otherwise, it needs to
be checked and marked if it's safe. If it's unsafe, an exception can
be thrown.
IMO the better approach is simply to forbid NUL in strings
Michele La Monaca scripsit:
I must confess I didn't read the entire thread. But, what exactly buys
us barring NUL in strings
Part of the design of Chicken is close integration with C. The ability
to share strings with C rather than constantly copying them as they pass
from Scheme to C and
Florian Zumbiehl scripsit:
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 \u?
John Cowan co...@mercury.ccil.org writes:
Michele La Monaca scripsit:
other than limiting the usefulness of the type and its powerful API
(while breaking a lot of things along the way)? Also, NUL is a valid
UTF-8 character.
Valid but useless. It has no significance whatever.
It has no
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 \u? JSON parsers
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
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?!
Florian Zumbiehl scripsit:
I am frankly sick of tools bending over backwards to support NUL.
I am frankly sick of people making up their own variants of standards,
creating all kinds of interoperability and security problems, and even more
of environments that make it unnecessarily
On Tue, Oct 14, 2014 at 9:14 AM, Florian Zumbiehl fl...@florz.de wrote:
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
Florian Zumbiehl scripsit:
As you are guaranteed to receive syntactically valid JSON documents,
you obviously don't need to worry about parsing failures.
In that case, the result is not rejected valid(!) input (it's valid
JSON, so nothing bogus about it, even if you happen to dislike NUL
13 matches
Mail list logo
