[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rapp-dev] assert(!error_return) if --enable-debug?
From: |
Hans-Peter Nilsson |
Subject: |
Re: [Rapp-dev] assert(!error_return) if --enable-debug? |
Date: |
Mon, 2 May 2011 05:45:44 +0200 |
> Date: Mon, 28 Mar 2011 18:04:18 +0200
> From: Hans-Peter Nilsson <address@hidden>
> How about adding asserts that the exported functions succeed (as
> in not returning an error code)?
Or rather, calls to abort() in the error arms of the driver
code, like
if (!RAPP_INITIALIZED()) {
RAPP_ABORT_FOR_ASSERTED_RETURNS();
return RAPP_ERR_UNINITIALIZED;
}
if (!line) {
RAPP_ABORT_FOR_ASSERTED_RETURNS();
return RAPP_ERR_PARM_NULL;
}
with RAPP_ABORT_FOR_ASSERTED_RETURNS() empty for normal
configurations, and calling rapp_abort() (which in turn calls
abort) for the new configuration option.
> The RAPP test-suite tests that verify that the proper error code
> is returned would have to be #if'd away, probably with an #else
> #warning "Tests verifying error codes are disabled", so I'm
> leaning towards a separate --enable- option, perhaps
> --enable-asserted-returns (default disabled); better names
> welcome.
I went with a sub-option of --enable-debug: thus
--enable-debug=no (aka. --disable-debug)
--enable-debug(=yes) ("normal" debug; -O0 and no -DNDEBUG=1)
and the new
--enable-debug=asserted-returns ("normal" but with abort calls)
I also refrained from any adjustments to the test-suite so
you'll see a lot of subtests calling abort for check if you try
that; without check, testing will fail for rapp_bitblt_copy_bin.
Hopefully this way no-one will see it as a kind of alternative
API but it will retain the intended usefulness.
brgds, H-P
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Rapp-dev] assert(!error_return) if --enable-debug?,
Hans-Peter Nilsson <=