Enough already with the KDE bug!

Enough already with the KDE bug!

[Hyman Rosen]

Martin von Loewis (martin@mira.isdn.cs.tu-berlin.de) writes:
> class KProcess { public: bool normalExit(); private: int status; };
> bool KProcess::normalExit()
> {
>   union { __typeof(  status  ) in; int i; } u;
>   return false;
> }
> 
> bash-2.00# g++ -c k.cc
> k.cc: In method `bool KProcess::normalExit()':
> k.cc: member `status' is a private member of class `KProcess'
> k.cc: warning: ANSI C++ forbids declaration `in' with no type

Enough with this bug report already. There's a patch for this
available in the KDE sources. It's not legal C++. The union
declares a new class, and it is not a friend of KProcess, so
it has no access to the private names of KProcess. So the
__typeof(status) in the union is illegal.

Re: Enough already with the KDE bug!

[Martin von Loewis]

> Enough with this bug report already. There's a patch for this
> available in the KDE sources. It's not legal C++. 

Wait a second. Of course this is not legal C++: __typeof is not
legal C++.

> The union
> declares a new class, and it is not a friend of KProcess, so
> it has no access to the private names of KProcess. So the
> __typeof(status) in the union is illegal.

If so, whose bug is it? The KDE sources say

bool KProcess::normalExit()
{
  return (pid != 0) && (!runs) && (WIFEXITED(status));
}

I cannot see a declaration of a class anywhere, here.  Are you saying
you cannot apply the WIFEXITED macro to a private variable? This is
strange, the Solaris man page of WIFEXITED does mention such a
restriction.

So maybe you are saying the implementation of WIFEXITED in glibc is
wrong. Well, maybe. But why was the bug fix then in KDE and not in
glibc?

Also, please note that typeof is a GNU extension. Where in the info
pages does it say that typeof fails when passing non-accessible C++
members? You are not trying to access the value, you only want the
type.

Regards,
Martin

Re: Enough already with the KDE bug!

[Joe Buck]

> Also, please note that typeof is a GNU extension. Where in the info
> pages does it say that typeof fails when passing non-accessible C++
> members? You are not trying to access the value, you only want the
> type.

typeof, like sizeof, depends only on the type.  But you can't take sizeof
an inaccessible member according to the C++ standard; it seems that
typeof should behave in the same way.

A private member is just that; client code is not supposed to be aware
of even the existence of private members.  Given this, the behavior
should not be a surprise.

Re: Enough already with the KDE bug!

[Raja R Harinath]

Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:
> So maybe you are saying the implementation of WIFEXITED in glibc is
> wrong. Well, maybe. But why was the bug fix then in KDE and not in
> glibc?

It's been fixed in glibc-2.0.6.  Here's the relevant info:

  1997-11-30 06:01  Ulrich Drepper  <drepper@cygnus.com>

       * posix/sys/wait.h (__WAIT_INT): Don't use complex version with
       __typeof for C++ since this fails for class members.
       Reported by Neal Becker <neal@ctd.comsat.com>.

  diff -durpN glibc-2.0.5c/posix/sys/wait.h glibc-2.0.6/posix/sys/wait.h
  --- glibc-2.0.5c/posix/sys/wait.h       Tue Nov  5 23:23:09 1996
  +++ glibc-2.0.6/posix/sys/wait.h        Sun Nov 30 00:11:13 1997
  @@ -38,7 +38,7 @@ __BEGIN_DECLS
   /* Lots of hair to allow traditional BSD use of `union wait'
      as well as POSIX.1 use of `int' for the status word.  */

  -#ifdef __GNUC__
  +#if defined __GNUC__ && !defined __cplusplus
   #define        __WAIT_INT(status)                                     \
     (__extension__ ({ union { __typeof(status) __in; int __i; } __u;    \
		      __u.__in = (status); __u.__i; }))

HTH
- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash