Glenn Fowler writes:
>
> On Mon, 5 Feb 2007 13:37:40 -0500 James Carlson wrote:
> > How is it possible that AST is so dependent on system internals that
> > use if <sys/isa_defs.h> "screws-up" the compilation?
>
> a header need not be directly included to foul up the works
> in an attempt to make some standards/extensions visible this
> header ended up tagging along and brought with it some unexpected
> macros/typedefs/prototypes
>
> if the iffe ("configure") scripts didn't see this header at build
> time, or if non-standard symbols happen to clash with ast implementation
> symbols, then conflicts could arise
That's exactly my question: rather than saying vaguely that it
"screws-up" the compilation, what actual problems are seen?
What are we looking at here?
Are our include files stepping into name spaces that are supposed to
be owned by applications? If so, then let's get some bugs filed where
we've made mistakes. We shouldn't allow portability problems to
survive.
Is AST walking into areas where it shouldn't be defining symbols? Are
we just seeing the tip of an iceberg here?
The issue is bigger than just the _LP64 symbol. I'm quite puzzled
that there could be a reasonable, portable application out there that
would be blown away by <stddef.h>. Something about that just doesn't
ring true to me.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
