Convert 3.2 sources to ISO C90
Stan Shebs
shebs@apple.com
Thu Jun 6 10:46:00 GMT 2002
law@redhat.com wrote:
>
> In message <3CFF96FE.68B68282@apple.com>, Stan Shebs writes:
> > law@redhat.com wrote:
> > >
> > > In message <200206061627.g56GRgg20707@duracef.shout.net>, Michael Elizabe
> > th
> > > Cha
> > > stain writes:
> > > > On hpux 10.20 and later, hpux cc has an option "-Ae" to enable
> > > > Ansi C, specifically including prototypes.
> > > More correctly -Ae enables "extended ANSI"; -Aa enables strict ANSI.
> > >
> > > I've managed to get things to build with the unbundled compiler using -Ae
> **********
> > and
> > > -Aa with various amounts of hackery. The problem with them is they muck u
> > p
> > > the namespace pretty badly and suddenly functions and structures you expec
> > t
> > > to find in the include files aren't there anymore and some which you don't
> > > expect suddenly exist (leading to wonderful problems in some GNU code whic
> > h
> > > at least used to blindly assume it should provide a typedef for uint32_t :
> > (
> >
> > Waitaminnit - you're saying you *can* build pure ISO code with the
> > bundled compiler, and the obstacles are either HP bugs (which you've
> > said they'll fix) or GCC bugs, which we can fix?
> NO. Read "unbundled" in my message. I've managed to build with the *BUNDLED*
> compiler using a variety of flags to get extended ansi behavior.
>
> The only success I've had with the bundled compiler has been on non-ANSI
> code.
Now I'm completely confused. Your first sentence says you managed to
build (GCC presumably) with bundled compiler + extended ansi behavior,
and your second sentence says that the bundled compiler only works on
non-ANSI code, which sounds like it contradicts your first sentence.
Do you mean that "extended ansi behavior" is required to compile GCC
in its current state?
Stan
More information about the Gcc
mailing list