This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC headers and DJGPP port
- To: eliz at is dot elta dot co dot il
- Subject: Re: GCC headers and DJGPP port
- From: Mike Stump <mrs at windriver dot com>
- Date: Mon, 17 Jul 2000 14:28:17 -0700 (PDT)
- Cc: djgpp-workers at delorie dot com, gcc at gcc dot gnu dot org
> Date: Mon, 17 Jul 2000 14:34:27 -0400 (EDT)
> From: Eli Zaretskii <eliz@delorie.com>
> To: Mike Stump <mrs@windriver.com>
> > From: Mike Stump <mrs@windriver.com>
> > Date: Mon, 17 Jul 2000 10:36:53 -0700 (PDT)
> >
> Sorry, I don't understand how can this ever work reliably.
Simple, gcc knows the target system, including details that affect
these things. Does it mean that gcc has to know a bit about target
system, sure. Welcome to gcc.
> I don't see how can GCC provide definitions that will never conflict
> with library internals. Please tell what am I missing.
> How about a system with its own stddef.h? Standard types such as
> the definition of NULL -- these are surely closely related to the
> internals of a library, right?
:-) Actually, this is the canonical example for of one that we prefer
our definition for. Understand why we #define it to __null and you'll
gain a better understanding of the issues.
varargs.h, is another good example. Ours works, it'll always work, we
prefer it, why not use it? Is your version safe with
-fstrict-aliasing? Are you sure? By using ours, we know ours is.