egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Oliver M. Kellogg]

Is it intended that the size of ulong in egcs-1.0.3a on a DEC Alpha,
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0b/egcs-2.90.29/include/sys/types.h
line 468, be set to 8 bytes?
    `typedef long unsigned int ulong;'
This declaration raises conflicts with other software, e.g. mico-2.1.0
wants to `typedef unsigned int ulong;'

Who's the culprit, EGCS or MICO? 
Is the name `ulong' reserved in some special way so that apps shouldn't 
attempt to redefine it in the first place?

Thanks,

Oliver M. Kellogg

Daimler-Benz Aerospace AG
Sensor Systems, Dept. VE3E3
D-89070 Ulm, Germany
phone:  (+49) 731 392-7138
fax:    (+49) 731 392-4255
e-mail: Oliver.Kellogg@vs.dasa.de

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Richard Henderson]

On Wed, Jul 15, 1998 at 06:25:04PM +0200, Oliver M. Kellogg wrote:
> Is it intended that the size of ulong in egcs-1.0.3a on a DEC Alpha,
> /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0b/egcs-2.90.29/include/sys/types.h
> line 468, be set to 8 bytes?

Actually, that definition appears in the system's <sys/types.h>.  What
you see here is an artifact of EGCS having tweeked the system header a
tad and kept a copy.

> Who's the culprit, EGCS or MICO? 
> Is the name `ulong' reserved in some special way so that apps shouldn't 
> attempt to redefine it in the first place?

MICO.  ulong has a long heritige of being defined in BSD header files,
from which DU is derived.  And it is _always_ unsigned long, never mind
the size of the actual type.

You should either turn on -D_POSIX_SOURCE (or some other appropriate
OS-specific switch) that removes BSD-specific bits from the global
namespace, or make MICO use a different type name.


r~

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Jeffrey A Law]

  In message < 9807151620.AA18101@gatekeeper.vs.dasa.de >you write:
  > Is it intended that the size of ulong in egcs-1.0.3a on a DEC Alpha,
  > /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0b/egcs-2.90.29/include/sys/types
  > .h
  > line 468, be set to 8 bytes?
  >     `typedef long unsigned int ulong;'
  > This declaration raises conflicts with other software, e.g. mico-2.1.0
  > wants to `typedef unsigned int ulong;'
  > 
  > Who's the culprit, EGCS or MICO? 
  > Is the name `ulong' reserved in some special way so that apps shouldn't 
  > attempt to redefine it in the first place?
The problem is either DEC or MICO, not egcs.

I don't have an ANSI reference handy, but I do not believe "ulong" is
a reserved type, and the definition in sys/types.h is thus polluting
the ANSI namespace.

jeff

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Per Bothner]

> I don't have an ANSI reference handy, but I do not believe "ulong" is
> a reserved type, and the definition in sys/types.h is thus polluting
> the ANSI namespace.

That should be "Posix namespace". <sys/types.h> is a Posix header, not an
ANSI header, and thus is free to add to the "user namespace", according
to ANSI, but not accordingto Posix.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Joe Buck]

 
> > I don't have an ANSI reference handy, but I do not believe "ulong" is
> > a reserved type, and the definition in sys/types.h is thus polluting
> > the ANSI namespace.

Per Bothner writes:
> That should be "Posix namespace". <sys/types.h> is a Posix header, not an
> ANSI header, and thus is free to add to the "user namespace", according
> to ANSI, but not accordingto Posix.

That is a bit confusing.  Clearly ANSI doesn't restrict what sys/types.h
does, but doesn't Posix?  That is, isn't it technically illegal under
Posix for sys/types.h to define ulong ?

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Per Bothner]

> That is a bit confusing.  Clearly ANSI doesn't restrict what sys/types.h
> does, but doesn't Posix?  That is, isn't it technically illegal under
> Posix for sys/types.h to define ulong ?

Correct.  That is reasonable clarification of what I said less clearly.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Joe Buck]

> > That is a bit confusing.  Clearly ANSI doesn't restrict what sys/types.h
> > does, but doesn't Posix?  That is, isn't it technically illegal under
> > Posix for sys/types.h to define ulong ?
> 
> Correct.  That is reasonable clarification of what I said less clearly.

Does/should fixinclude try to fix Posix violations, or only ANSI/ISO
violations?  (I suppose it can't do it in general since many gcc targets
aren't really Posix).

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Richard Henderson]

On Thu, Jul 16, 1998 at 05:47:31PM -0700, Joe Buck wrote:
> Does/should fixinclude try to fix Posix violations, or only ANSI/ISO
> violations?  (I suppose it can't do it in general since many gcc targets
> aren't really Posix).

No, that way lies madness.  I'm actually surprised we do what we do
with fixincludes, instead of coping out and stating that you only get
an ISO environment if the vendor provides one.


r~

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Joe Buck]

> On Thu, Jul 16, 1998 at 05:47:31PM -0700, Joe Buck wrote:
> > Does/should fixinclude try to fix Posix violations, or only ANSI/ISO
> > violations?  (I suppose it can't do it in general since many gcc targets
> > aren't really Posix).
> 
> No, that way lies madness.  I'm actually surprised we do what we do
> with fixincludes, instead of coping out and stating that you only get
> an ISO environment if the vendor provides one.

That copout would have meant "no gcc on SunOS4 unless you buy Sun's
proprietary ANSI C compiler".  Not really in the FSF spirit, is it?

Also, fixincludes doesn't try to provide an ISO environment, only to fix
things that directly conflict with ISO if they can be fixed without
making things worse.

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Richard Henderson]

On Mon, Jul 20, 1998 at 09:09:21AM -0700, Joe Buck wrote:
> That copout would have meant "no gcc on SunOS4 unless you buy Sun's
> proprietary ANSI C compiler".  Not really in the FSF spirit, is it?

Alternately, "install glibc". 

(Which is bit-rotten for SunOS now, but worked at one time.)


r~

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Ulrich Drepper]

jbuck@synopsys.com (Joe Buck) writes:

> That is a bit confusing.  Clearly ANSI doesn't restrict what sys/types.h

Of course not, sys/types.h is a header introduced in POSIX.

> does, but doesn't Posix?

Yes, see POSIX.1, annex C.

> That is, isn't it technically illegal under Posix for sys/types.h to
> define ulong ?

Not withing the POSIX namespace.  Everything is possible if you say
you want an extended namespace (like in glibc where yo can use
_GNU_SOURCE).

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: egcs-1.0.3a on DEC Alpha / DU4.0b: typedef of ulong in types.h

[Richard Henderson]

On Thu, Jul 16, 1998 at 12:10:44AM -0600, Jeffrey A Law wrote:
> I don't have an ANSI reference handy, but I do not believe "ulong" is
> a reserved type, and the definition in sys/types.h is thus polluting
> the ANSI namespace.

You don't get an ISO or even POSIX namespace unless you give
the compiler certain preprocessor flags.  -D_POSIX_SOURCE is
probably what MICO would prefer.


r~