Re: [Cgreen-users] [Cgreen-devel] When CGreen runs out of memory

[Marcus B. <ma...@la...>]

Hi...

Andreas Schneider wrote:
> well, cgreen is a library and a library should never call exit().

Why not?

Your assertion is incorrect. CGreen is a tool, not a library. The code
under test is the client code in this case. The most common use case for
a unit tester is that it is testing the low level *parts* of an application.

It can be used to test the whole app., but that is not the primary use
case. The reason for having the tests in the same language as the code
is to facilitate writing low level tests. An application test would
probably have an intermediate shell invocation or whatever the external
interface was.

> The test developer should be able to cleanup his own things!

If they could always do that, they wouldn't need tests now, would they? :)

I did say that this is a tool for people writing their first unit tests.

> And go back to the application :)

The only time this would happen is if CGreen is embedded in something
else. In this case it would have an indirect connection (shell/sockets)
to read the output. I don't think you would want to couple your
IDE/Workbench/CruiseControl to a CGreen crash.

We could add a C level driver API later, but I don't want to do that for
version 1.0. I just want to get the thing out there.

> Cleanup the memory and return a FATAL error to the test application. Use 
> functions with return values instead of void.

The whole point of what I'm saying. I'd prefer not to have a manual
maintenance pain if I can design my way out of it. That stuff died out
last century, because it's damn ugly.

There are OS project reasons for this. I want to fight every last line
of clutter in the top level. If the code is clean, we get more
contributers down the line.

Even if you don't agree, which is fair enough, I am going to be the one
having to maintain everything in 5 years time. Five years of chasing
return codes will really add up. Have a heart.

> Have you ever looked at talloc?

Yes, and obstacks and some other server allocators. It was this stuff I
was thinking of when I posted. I don't want to have an external
dependency on anything other than the C standard library though.
Besides, we don't need anything that complicated. I was just going to
keep a list of things to free().

> 
> Cheers,
> 
> 
> 	-- andreas

yours, Marcus