Re: Convert 3.2 sources to ISO C90

[Stan Shebs <shebs at apple dot com>]

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