Including assert.h multiple times.

[Durward McDonell]

I am having some trouble with assert.h getting included multiple
times.  I've looked at assert.h, and I believe I understand how it
works.  In particular, I believe the following (this is all assuming
NDEBUG is never set):

1. The first time through assert.h, it declares 'extern
   __assert_fail(...)', 'extern __assert_perror(...)', and 'extern
   __assert(...)'.  It also defines a macro assert().  (It also
   declares other things that I'm not concerned with here.)

2. The second and subsequent times through, it undefines the assert()
   macro, makes the extern declarations, and redefines the assert()
   macro.

The problem I'm seeing is that at some point, assert.h is being
included, but effectively the assert() macro is not being undefined.
The result is that when assert.h declares extern __assert(...), the
preprocessor makes a macro substitution, and thus I get a second, and
inconsistent, declaration of extern __assert_fail(...).  This also
produces "errors" about the including files making "incorrect"
invocations of __assert_fail(...).

I grepped through all the relevant source code, and I could find no
mention of _ASSERT_H that might screw things up.  I also put things
like

#ifdef assert
#warning "assert shouldn't be defined here!"
#endif

at appropriate places in assert.h, but evidently the preprocessor
thinks that assert() is NOT defined in the body of assert.h, but makes
the substitution anyway.

I effectively solved the problem by commenting out the declaration of
extern __assert(...), since assert.h claims that it is never used
anyway, and only there for standard compliance.  But this doesn't seem
like the right solution.

My main question here is whether this is a known bug, or something
anyone's seen before.  I tried to make a small example, but couldn't
come up with anything that reproduced the problem except the code I
was using.  FWIW, we're using ACE/TAO, which is huge, and has been
known to exercise bugs in compiler/preprocessor code.  The gcc-bug
list is my next stop, if no one here is able to shed any light on this
problem.

Thanks.

-- 
Durward McDonell                                   address@hidden