LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.02.06 10:07 "Re: assertions, and building with DEBUG/NDEBUG", by Joris Van Damme
Frank,
> It appears these assertions are being used to call to attention problems
> in these files for developers, and are intended to be compiled out in
> production software.
In my book that is exactly the definition of an assertion. Us developers
make assumptions about the logical state of execution at points in the code.
Sometimes we're dead sure, if (a==1), then on the next line we can safely
assume that a does not equal 2. Sometimes the code flow and logic is more
complicated, and we factor in that we might be mistaking about some of our
assumptions. That's what assert is for, it double-checks as long as we're in
the testing stage, and when that stage is done and none of our assumptions
turned out fawlty and/or the ones that did got corrected and it's time to
produce production software, the asserts are compiled out without the need
for editing.
If assert is not what exactly this any more, then one ought to re-invent it,
because such a construct is a basic and badly needed programming tool.
In a related place in the code I find the following:
assert(fi!=0xFFFFFFFF);
if (fi==0xFFFFFFFF)
{
TIFFErrorExt(...)
return();
}
That might just be code by my hand, as I do such constructs. It means that
I'm about 99.99% sure it's a safe assumption that fi cannot possibly equal
0xFFFFFFFF at that point. I'd like to get some reassurance from the testing
stage that my assumption is indeed correct, and some feedback if/when it
isn't, and some proper warning if auxilliary code should change in such a
way that it has an impact on the correctness of this assumption here, so I
put in the assert. And I'm also considering it's (very) remotely possible my
assumption might be incorrect in some very obscure case that doesn't get
caught in the testing stage, so this not being a critical path I'm putting
in extra security with a safe and correct error return if ever my assumption
should turn out incorrect in the production software stage where the assert
is compiled out. Again, I find I for one cannot possibly produce code
without such tools, so if assert should not be the tool I think it is,
please point me to another.
> I am contemplating modifying tiffiop.h to explicitly define NDEBUG if
> DEBUG is not defined, before including assert.h. This would mean that
> assertions are compiled out by default, and only included if DEBUG is
> explicitly requested. I would also change Makefile.vc to define DEBUG for
> the debug build case.
>
> Does anyone have thoughts on a more appropriate approach?
In my own codes, either _DEBUG or NDEBUG is defined. Note the underscore
before DEBUG. Its definition is double-checked in my most basic system
header file that is included all over the place, like this:
#ifndef _DEBUG
#ifndef NDEBUG
#error the library needs _DEBUG or NDEBUG defined, depending on this being a
debug or release build
#endif
#endif
#ifdef _DEBUG
#ifdef NDEBUG
#error the library needs either _DEBUG or NDEBUG defined, depending on this
being a debug or release build, but not both
#endif
#endif
At the time, I believed defining either _DEBUG or NDEBUG was the de facto
most common approach, but you guys are way more knowledgeable on the many
platforms out there so please don't take this too serious. In any case, the
_DEBUG and/or NDEBUG defines do impact the assert.h in the way I intend it
as per above explanation on both the MSVC and Borland compilers on the
Windows platform, that much I have verified. For example, here's the
relevant snippet from assert.h on the MSVC platform:
#ifdef NDEBUG
#define assert(_Expression) ((void)0)
#else
#ifdef __cplusplus
extern "C" {
#endif
_CRTIMP void __cdecl _wassert(_In_z_ const wchar_t * _Message, _In_z_ const
wchar_t *_File, _In_ unsigned _Line);
#ifdef __cplusplus
}
#endif
#define assert(_Expression) (void)( (!!(_Expression)) ||
(_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )
#endif /* NDEBUG */
More to the point, as to howcome some assertions play up, I'll be looking
into that right away and get back to you.
Best regards,
Joris