A glibc or egcs bug?

A glibc or egcs bug?

[H.J. Lu]

This is from glibc 2.1:

# gcc -v
Reading specs from
/usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/egcs-2.90.20/specs
gcc version egcs-2.90.20 971201 (gcc2-970802 experimental)
# gcc -S w.cc
w.cc: In function `int foo()':
w.cc:48: no matching function for call to `__WAIT_STATUS::._2 (int *)'
w.cc:38: candidates are: __WAIT_STATUS::._2(const {anonymous union} &)
w.cc:38:                 __WAIT_STATUS::._2()


-- 
H.J. Lu (hjl@gnu.org)
--w.cc--
union wait
  {
    int w_status;
    struct
      {

	unsigned int __w_termsig:7;  
	unsigned int __w_coredump:1;  
	unsigned int __w_retcode:8;  
	unsigned int:16;







      } __wait_terminated;
    struct
      {

	unsigned int __w_stopval:8;  
	unsigned int __w_stopsig:8;  
	unsigned int:16;






      } __wait_stopped;
  };

typedef union
  {
    union wait *__uptr;
    int *__iptr;
  } __WAIT_STATUS __attribute__ ((__transparent_union__));


extern int wait  (__WAIT_STATUS __stat_loc)  ;

int
foo ()
{
  int status;

  wait (&status);

  return status;
}

Re: A glibc or egcs bug?

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> This is from glibc 2.1:
> 
> # gcc -v
> Reading specs from
> /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/egcs-2.90.20/specs
> gcc version egcs-2.90.20 971201 (gcc2-970802 experimental)
> # gcc -S w.cc
> w.cc: In function `int foo()':
> w.cc:48: no matching function for call to `__WAIT_STATUS::._2 (int *)'
> w.cc:38: candidates are: __WAIT_STATUS::._2(const {anonymous union} &)
> w.cc:38:                 __WAIT_STATUS::._2()

I've changed glibc earlier this week to not use transparent unions for C++.
This is unfortunate since the avoiding casts is always good but maybe it's
too difficult to change the C++ lookup handling.  Jason?

-- Uli
---------------.      drepper at gnu.org  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A glibc or egcs bug?

[H.J. Lu]

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > This is from glibc 2.1:
> > 
> > # gcc -v
> > Reading specs from
> > /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/egcs-2.90.20/specs
> > gcc version egcs-2.90.20 971201 (gcc2-970802 experimental)
> > # gcc -S w.cc
> > w.cc: In function `int foo()':
> > w.cc:48: no matching function for call to `__WAIT_STATUS::._2 (int *)'
> > w.cc:38: candidates are: __WAIT_STATUS::._2(const {anonymous union} &)
> > w.cc:38:                 __WAIT_STATUS::._2()
> 
> I've changed glibc earlier this week to not use transparent unions for C++.
> This is unfortunate since the avoiding casts is always good but maybe it's
> too difficult to change the C++ lookup handling.  Jason?
> 

But glibc 2.1 971205 still has the old code.

-- 
H.J. Lu (hjl@gnu.org)

Re: A glibc or egcs bug?

[Neal Becker]

The related question is, why are we hitting this union wait stuff at
all, if we don't ask for -D_BSD?  I thought glibc would favor POSIX in 
cases of conflict.  Using the old BSD union wait is hardly ever
needed.

Re: A glibc or egcs bug?

[Ulrich Drepper]

Neal Becker <neal@ctd.comsat.com> writes:

> The related question is, why are we hitting this union wait stuff at
> all, if we don't ask for -D_BSD?  I thought glibc would favor POSIX in 
> cases of conflict.  Using the old BSD union wait is hardly ever
> needed.

We have the feature of the transparent unions, so why not use it.  It
is much cleaner than requiring defines.

-- Uli
---------------.      drepper at gnu.org  ,-.   Rubensstrasse 5
Ulrich Drepper  \    ,-------------------'   \  76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A glibc or egcs bug?

[Roland McGrath]

> The related question is, why are we hitting this union wait stuff at
> all, if we don't ask for -D_BSD?  I thought glibc would favor POSIX in 
> cases of conflict.  Using the old BSD union wait is hardly ever
> needed.

This is not a case of conflict.  Both can be supported without conflict (in
C).  The default is to include all features that don't conflict with
POSIX-standard features.