Mail Archives: djgpp-workers/2000/07/20/03:50:07
> > > Anyway, one reason that __null might cause trouble is that it breaks
> > > previous versions of the library which were compiled with different
> > > definition of NULL. I think we've been discussing that on the DJGPP
> > > developers list to death.
[...]
> Seriously, though: the conclusion was that we didn't like the
> redefinition of NULL in C++ headers (see my other message for the
> problems this causes).
So you had all this discussion to agree on a mental state (you don't
like it)? I had hoped you could have concluded that it either does or
does not break the library. If it does break the library, exactly why?
If it does not break the library, what is the problem?
Please try to be technical instead of political - especially if you
are asking the same from GCC developers!
> But we couldn't understand why does the C++ compiler redefines NULL
> in its headers, so we couldn't find a solution that would satisfy us
> all and avoid breaking the C++ compiler at the same time. Perhaps
> you could help.
It's very easy. In C++, NULL is an "implementationdefined C++ null
pointer constant", according to 18.1, [lib.support.types]/4. That
means, "possible definitions include 0 and 0L, but not (void*)0".
If you define NULL as 0, you find that
#include <stdlib.h>
void foo(int);
void foo(int*);
int main()
{
foo(NULL);
}
will compile flawlessly and invoke the first function, even though it
is probably the author probably meant to express a pointer. The reason
is that passing 0 into an int is an exact match, whereas converting it
to int* is a conversion. Please note that the exact meaning of this
program could depend on the platform - if the parameter is a typedef
that is "long int" on some systems and "int" on others, the meaning of
this program changes.
The same problem exists with
throw NULL;
which does not do what the user would expect (i.e. it throws an int,
or long - not a null pointer). There are a few more common program
mistakes involving a misunderstanding of NULL. Those can only be
detected if the compiler *knows* that this used to be NULL, hence the
__null keyword.
I believe this feature of g++ has proven useful, and I'd certainly
expect that all ports of g++ support it.
Regards,
Martin
- Raw text -