[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] incorrect warning during compilation

From: Peter Bex
Subject: Re: [Chicken-hackers] incorrect warning during compilation
Date: Fri, 11 Jul 2014 08:55:08 +0200
User-agent: Mutt/

On Wed, Jul 09, 2014 at 12:00:38PM +0200, Kristian Lein-Mathisen wrote:
> Cool! And the commit even shows up with Felix as the author. This
> pathes-over-email thing works really nicely :) Never seen it in action like
> this before.

Yeah, git, for all its flaws, performs the tasks it was designed for
very well.

> So I'm curious, are there no tests for things like this? Might it be a good
> idea? Is there an official test-policy for chicken-core anywhere I can read
> up on?

I was wondering about a test too, but decided it's not really worth it.
We have very few tests for the FFI, only a few basic tests and a few
regression tests for bugs that have cropped up in the past.
There's no official test policy except "try to test as much as is
reasonable" and "try to add a regression test when fixing nasty bugs".

> (use test)
> (test "parameterized scheme-pointer"
>       "ABC"
>       ((foreign-lambda* c-string (((scheme-pointer unsigned-char) x))
> "x[0] = 65; return(x);")
>        "xBC"))

We can't use the test egg in core.  However, there are so many hand-
rolled assertion/test-like macros that I've often wondered if it would
benefit us to make a simple test library part of core.  Core itself
could benefit from an improved test suite library, and eggs wouldn't
need an additional dependency for testing.  I don't think I want to
literally put the test egg into core.  I like the simplicity of the API
but the implementation is a bit messy and it's a bit hard to modify
the way it writes its output (try changing it to output some HTML,
for example).  This may just be a documentation problem, though.

Anyway, your test would probably succeed even if the pointer type would
be incorrect.  It would just compile with a warning (which gets lost
in the noise).  If you change the index to 1 or 2, it might be a better
test since it would fail when the pointer type would be anything larger
than a char due to the address calculation ending up somewhere beyond
the string.  Additionally, we could compile the test with -Wall -Werror
for example, to catch C type errors.  Would you care to write a complete
patch to add FFI tests?  You can mail it with "git format-patch"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]