GCC headers and DJGPP port

[Martin v. Loewis]

> I'm not sure what GCC's notion of NULL are you talking about.  We
> cannot use __null in C headers unconditionally, because it will cause
> unresolved externals in C programs, right?

Wrong. As there is no declaration of __null, and as this is not a
function, it will cause a compile error, not an unresolved symbol.

> Use of __null conditioned on __cplusplus is questionable, since
> libc.a is not compiled with that definition of NULL.  Am I missing
> something?

Yes. Please re-read my message elaborating on __null semantics. Usage
of __null does not result in an assembler-level reference to a symbol
named __null; there is no such symbol. As a result, libc.a does not
need to provide anything.

Instead, cc1plus will emit 'zero' immediate values in assembler,
depending on the assembler language (e.g. clearing eax).

> We did use #undef to solve the immediate problem, but it looked like a
> brute-force and potentially dangerous (for C++ programs) solution.  I
> wonder if there's a better one.

Yes. Try to trust the GCC-provided headers more than you currently do.

Regards,
Martin