On Wed, Oct 08, 2014 at 01:31:30AM +0400, Oleg Kolosov wrote:
On Oct 7, 2014, at 10:04 PM, Peter Bex peter@xs4all.nl wrote:
The overhead of calling C should be pretty minimal in the usual cases,
unless strings are the only problem. If it's the only dealbreaker,
I think that should be
I hope no one minds me jumping in to add my two cents...
On Wed, Oct 8, 2014 at 12:16 AM, Peter Bex peter@xs4all.nl wrote:
On Wed, Oct 08, 2014 at 01:31:30AM +0400, Oleg Kolosov wrote:
On Oct 7, 2014, at 10:04 PM, Peter Bex peter@xs4all.nl wrote:
It was discussed before on this list,
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
to C will simply be a matter of passing a pointer.
+1 to that.
The
On Wed, Oct 08, 2014 at 11:54:06AM -0400, John Cowan wrote:
Peter Bex scripsit:
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
Am 08.10.2014 um 19:46 schrieb Peter Bex:
On Wed, Oct 08, 2014 at 11:54:06AM -0400, John Cowan wrote:
Peter Bex scripsit:
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.
On Wed, Oct 08, 2014 at 08:04:17PM +0200, Jörg F. Wittenberger wrote:
In this particular case I will be forced to decide my priorities: I'm
sitting on some improvements and threading fixes and cleanups I've been
talking about on once about a time. Currently I'm busy documenting
other
The foreign-primitive form may return multiple values with the C_values
function, but its expansion is always declared to return a (single)
undefined value. This triggers invalid ##sys#c-w-v specializations for
single-valued producers where multiple values may in fact result.
This fixes that
On Wed, Oct 08, 2014 at 06:56:29AM -0700, Daniel Leslie wrote:
I hope no one minds me jumping in to add my two cents...
All comments are very welcome!
On Wed, Oct 8, 2014 at 12:16 AM, Peter Bex peter@xs4all.nl wrote:
On Wed, Oct 08, 2014 at 01:31:30AM +0400, Oleg Kolosov wrote:
On Oct
On Wed, Oct 8, 2014 at 11:05 AM, Peter Bex peter@xs4all.nl wrote:
How so? It's the correct Schemely way of handling strings, to disallow
embedded NUL bytes.
What I was eluding to is that it seems to me that Chicken is the
Scheme that can generally be expected to make design choices which
Peter Bex scripsit:
Thanks for speaking up, I hadn't considered how big of a problem this
would be for large, existing projects. We could possibly make it a
runtime option, so the checking (or just the enforcing) could be enabled
or disabled at will.
Here are my suggestions for staging this
On Oct 8, 2014, at 11:16 AM, Peter Bex peter@xs4all.nl wrote:
On Wed, Oct 08, 2014 at 01:31:30AM +0400, Oleg Kolosov wrote:
On Oct 7, 2014, at 10:04 PM, Peter Bex peter@xs4all.nl wrote:
The overhead of calling C should be pretty minimal in the usual cases,
unless strings are the only
11 matches
Mail list logo
