[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/1.4.2.3i |
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"
Cheers,
Peter
--
http://www.more-magic.net