Re: C++ vs. glibc/Hurd/Mach headers

2016-12-04 Thread Samuel Thibault 
Hello,

Thomas Schwinge, on Mon 28 Nov 2016 12:05:44 +0100, wrote:
> > > In file included from /usr/include/errno.h:35:0,
> > >  from :1:
> > > /usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
> > > /usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to 
> > > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> > >err = EIEIO;
> > >  ^
> > > /usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to 
> > > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> > >err = ENOMEM;
> > >  ^
> > > /usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to 
> > > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> > >err = EINVAL;
> 
> This remains to be fixed; can you please commit your patch?

I guess I misread my test results, I didn't have any fix for this, but
I have now commited it.

> > The HURD_MSGPORT_RPC seems missing casts between kern_error and error_t
> > indeed.
> 
> Thanks for changing this code.  Though, the explicit casts are also not
> completely ideal, as they now hide other kinds of problems, for example:
> 
> $ echo -e '#include \n#include \n#include 
> \nvoid f(){ error_t err = 
> HURD_MSGPORT_RPC(,,,); }' | gcc -D_GNU_SOURCE -x c - -S -o 
> /dev/null -O2
> 
> ... in C compilation mode now no longer diagnoses "error: incompatible
> types when assigning [...]".  Oh well...  ;-/

Sure, we can't catch everything anyway.

Samuel

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-28 Thread Thomas Schwinge 
Hi!

On Sun, 27 Nov 2016 17:14:26 +0100, Samuel Thibault  
wrote:
> Thomas Schwinge, on Sat 26 Nov 2016 19:53:34 +0100, wrote:
> > When changing the GDB source code to use kern_return_t (or int) instead
> > of error_t, I still see hurd.h:__hurd_fail and
> > hurd/signal.h:HURD_MSGPORT_RPC choke on their own error_t usage:
> > 
> > $ echo -e '#include \n#include \n#include 
> > \n#include \nvoid f(){ kern_return_t err = 0; err = 
> > thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
> > -D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
> 
> Don't use 0, but ESUCCESS.

;-) I do know about ESUCCESS (I added it), but the literal 0 (int) here
are to model the fact that Mach API calls have a return type of
kern_return_t (int).  (Thus, I will change GDB's "err" variables from
error_t to kern_return_t.)

> > In file included from /usr/include/errno.h:35:0,
> >  from :1:
> > /usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
> > /usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = EIEIO;
> >  ^
> > /usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = ENOMEM;
> >  ^
> > /usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = EINVAL;

This remains to be fixed; can you please commit your patch?

> The HURD_MSGPORT_RPC seems missing casts between kern_error and error_t
> indeed.

Thanks for changing this code.  Though, the explicit casts are also not
completely ideal, as they now hide other kinds of problems, for example:

$ echo -e '#include \n#include \n#include 
\nvoid f(){ error_t err = HURD_MSGPORT_RPC(,,,); 
}' | gcc -D_GNU_SOURCE -x c - -S -o /dev/null -O2

... in C compilation mode now no longer diagnoses "error: incompatible
types when assigning [...]".  Oh well...  ;-/


Grüße
 Thomas

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-27 Thread Samuel Thibault 
Brent W. Baccala, on Fri 25 Nov 2016 17:00:50 -1000, wrote:
> In addition to what Thomas has described, the ports library is unusable with
> C++ because struct port_info has a member named "class".

I have just fixed it.

> Also, the initializer syntax used in /usr/include/refcount.h is unusable with
> g++.  For example:
> 
>     209   const union _references op =
>     210 { .references = { .weak = ~0U, .hard = 1} };
> 
> generates a compiler error:
> 
> sorry, unimplemented: non-trivial designated initializers not supported

I'm amazed how C++ still hasn't caught up on such basic useful feature.
Of course C++ is about objects, but structures are useful to initialize
nicely too... Anyway, fixed it too.

Samuel

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-27 Thread Samuel Thibault 
Samuel Thibault, on Sun 27 Nov 2016 17:14:26 +0100, wrote:
> > In file included from /usr/include/errno.h:35:0,
> >  from :1:
> > /usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
> > /usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = EIEIO;
> >  ^
> > /usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = ENOMEM;
> >  ^
> > /usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to 
> > ‘error_t {aka __error_t_codes}’ [-fpermissive]
> >err = EINVAL;
> 
> The HURD_MSGPORT_RPC seems missing casts between kern_error and error_t
> indeed.

Although the problem is actually that you passed 0 instead of ESUCCESS,
but it'd be very inconvenient to have to pass ESUCCESS. So I have
commited the cast.

Samuel

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-27 Thread Samuel Thibault 
Hello,

Thomas Schwinge, on Sat 26 Nov 2016 19:53:34 +0100, wrote:
> When changing the GDB source code to use kern_return_t (or int) instead
> of error_t, I still see hurd.h:__hurd_fail and
> hurd/signal.h:HURD_MSGPORT_RPC choke on their own error_t usage:
> 
> $ echo -e '#include \n#include \n#include 
> \n#include \nvoid f(){ kern_return_t err = 0; err = 
> thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
> -D_GNU_SOURCE -x c++ - -S -o /dev/null -O2

Don't use 0, but ESUCCESS.

> In file included from /usr/include/errno.h:35:0,
>  from :1:
> /usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
> /usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to 
> ‘error_t {aka __error_t_codes}’ [-fpermissive]
>err = EIEIO;
>  ^
> /usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to 
> ‘error_t {aka __error_t_codes}’ [-fpermissive]
>err = ENOMEM;
>  ^
> /usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to 
> ‘error_t {aka __error_t_codes}’ [-fpermissive]
>err = EINVAL;

The HURD_MSGPORT_RPC seems missing casts between kern_error and error_t
indeed.

Samuel

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-26 Thread Thomas Schwinge 
Hi!

On Sat, 26 Nov 2016 13:36:22 +0100, Samuel Thibault  
wrote:
> Thomas Schwinge, on Fri 25 Nov 2016 12:46:33 +0100, wrote:
> > Additionally to the issues Samuel pointed
> > out in 
> > (still unresolved),
> 
> ?
> 
> I can include hurd/signal.h fine from c++. The second part of my patch
> was applied

Right, hurd/signal.h's hurd_self_sigstate, _hurd_critical_section_lock,
and _hurd_critical_section_unlock have been fixed, but...

> and IIRC we made some changes to error_t.

... I don't see any such changes?

For GDB, the following is expected to work:

$ echo -e '#include \n#include \n#include 
\n#include \nvoid f(){ error_t err = 0; err = 
thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
-D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
In file included from /usr/include/errno.h:35:0,
 from :1:
/usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
/usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EIEIO;
 ^
/usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = ENOMEM;
 ^
/usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EINVAL;
 ^
: In function ‘void f()’:
:5:25: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:50: error: invalid conversion from ‘kern_return_t {aka int}’ to 
‘error_t {aka __error_t_codes}’ [-fpermissive]
In file included from /usr/include/hurd/userlink.h:27:0,
 from /usr/include/hurd/port.h:25,
 from /usr/include/hurd.h:41,
 from :3:
:5:67: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:67: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:67: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]

When changing the GDB source code to use kern_return_t (or int) instead
of error_t, I still see hurd.h:__hurd_fail and
hurd/signal.h:HURD_MSGPORT_RPC choke on their own error_t usage:

$ echo -e '#include \n#include \n#include 
\n#include \nvoid f(){ kern_return_t err = 0; err = 
thread_get_state(0,0,0,0); err = HURD_MSGPORT_RPC(0,0,0,0); }' | g++ 
-D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
In file included from /usr/include/errno.h:35:0,
 from :1:
/usr/include/hurd.h: In function ‘int __hurd_fail(error_t)’:
/usr/include/hurd.h:60:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EIEIO;
 ^
/usr/include/hurd.h:64:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = ENOMEM;
 ^
/usr/include/hurd.h:68:13: error: invalid conversion from ‘int’ to ‘error_t 
{aka __error_t_codes}’ [-fpermissive]
   err = EINVAL;
 ^
In file included from /usr/include/hurd/userlink.h:27:0,
 from /usr/include/hurd/port.h:25,
 from /usr/include/hurd.h:41,
 from :3:
: In function ‘void f()’:
:5:73: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:73: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]
:5:73: error: invalid conversion from ‘int’ to ‘error_t {aka 
__error_t_codes}’ [-fpermissive]


Grüße
 Thomas

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-26 Thread Samuel Thibault 
Thomas Schwinge, on Fri 25 Nov 2016 12:46:33 +0100, wrote:
> Additionally to the issues Samuel pointed
> out in 
> (still unresolved),

?

I can include hurd/signal.h fine from c++. The second part of my patch
was applied, and IIRC we made some changes to error_t.

Samuel

Re: C++ vs. glibc/Hurd/Mach headers

2016-11-25 Thread Brent W. Baccala 
On Fri, Nov 25, 2016 at 1:46 AM, Thomas Schwinge 
wrote:

> Hi!
>
> Motivation for bringing this up again: GDB has recently switched from
> using a C to a C++ compiler.  GDB, for obvious reasons, needs to access
> low-level Hurd/Mach interfaces.
>
>
I've also had problems compiling hurd code using g++.

In addition to what Thomas has described, the ports library is unusable
with C++ because struct port_info has a member named "class".

Also, the initializer syntax used in /usr/include/refcount.h is unusable
with g++.  For example:

209   const union _references op =
210 { .references = { .weak = ~0U, .hard = 1} };

generates a compiler error:

sorry, unimplemented: non-trivial designated initializers not supported

To reproduce both problems, just create a file containing the line #include
 and try to compile it with g++.  It doesn't matter if you
put it inside an extern "C" block, either.

agape
brent