2008.12.17 20:54 "[Tiff] Deleting tags from a directory", by Frank Warmerdam

2009.02.06 10:07 "Re: [Tiff] assertions, and building with DEBUG/NDEBUG", by

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