Re: CVS commit: src/regress/lib/libc

["Julio M. Merino Vidal" <jmmv84%gmail.com@localhost>]

On Jan 20, 2008 4:34 AM, Brian Ginsbach <ginsbach%netbsd.org@localhost> wrote:
> On Sat, Jan 19, 2008 at 09:17:40PM +0100, Julio M. Merino Vidal wrote:
> > On Jan 19, 2008, at 5:10 PM, Brian Ginsbach wrote:
> >
> > >On Sat, Jan 19, 2008 at 03:19:13PM +0200, Antti Kantee wrote:
> > >>
> > >>Shouldn't new tests be written for atf instead of the old
> > >>framework?  >
> > >
> > >It would if the ATF API was in C :-(.  I was easily able to knock
> > >this out.  I did look at the ATF stuff but the lack of API
> > >documentation, harry C++ macroness and no C API kept me away.  I
> > >felt some test is better than no test.
> >
> > The macros are there, precisely, to hide many C++ constructions that
> > many developers would not be comfortable about.  In many cases, your
> > tests will only include a couple of macros here and there, and then
> > include your plain C testing code.  Voila, no visible C++ code.
> >
>
> Personally I'd like no C++ at all.  For C it would be nice to just
> #include <atf/atf.h> or similar.

Well, that's on the TODO list ;-)

> I also think it would be better not to rely on macro magic even
> for C++.  If macros are needed to hide the complexity then maybe
> that says something?

It is not the complexity per se, but the C++ itself that I'm sure
scares some developers.

> It didn't seem that the macros would work very well inside a loop.

A loop... to do what? Define the test cases?

>  It
> made no sense to write basically the same test either as several source
> files or as sequences of AFT_TEST_CASE(), ATF_TEST_CASE_HEAD(),
> ATF_TEST_CASE_BODY().

What do you mean with several source files?  Put each of the above
macros in one?  The way it is now, a test program is nothing else than
an interface for a collection of test cases defined with those macros.

I'm just trying to understand where the confusions come from to resolve them...

>  Nor did it seem like ATF would lend it self to
> a data-driven test driver for a function.

For this, maybe look at the tests in atf/tests/formats.  They
basically test some parsers by feeding different data sets to them.

> > I have a C-only API in mind... but that will take a non-trivial
> > amount of effort to write.
>
> I can believe it because the C++ looks very complicated.  I'd like
> to help if I could.  I can see where the reliance on multiple
> classes, inheritance, etc. will make coming up with a C-only API
> non-trivial.

It really is not that complex (the API).  You may want to look at the
shell-based one, which should be on par as regards features but is
simpler (and there you don't have classes nor inheritance, but it
works :-) ). The complexity comes from all the tiny details that these
things do underneath. Add to that the lack of data structures in C...
which is basically why it was discarded; too much initial effort to do
trivial stuff.

> Have you looked at the C API used by the Linux Test Project (LTP)?
> I believe that at least this part of the LTP and ATF are trying to
> solve the same "problem".  (Note I have a little experience with
> a LTP predecessor -- recall that SGI gave LTP to the Linux community
> -- ask off-list if your interested in more details.)

No, I haven't, but will try to.

-- 
Julio M. Merino Vidal <jmmv84%gmail.com@localhost>
The Julipedia - http://julipedia.blogspot.com/