[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

C++ vs. glibc/Hurd/Mach headers

From: Thomas Schwinge
Subject: C++ vs. glibc/Hurd/Mach headers
Date: Fri, 25 Nov 2016 12:46:33 +0100
User-agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)


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.

<https://savannah.gnu.org/bugs/?32693> "GNU/Hurd headers don't pass c++"
has been closed as "invalid".  Additionally to the issues Samuel pointed
out in <https://www.sourceware.org/ml/libc-alpha/2007-08/msg00001.html>
(still unresolved), I now also ran into:

    $ echo -e '#include <errno.h>\n#include <mach.h>\nvoid f(){ error_t err = 
thread_get_state(0,0,0,0); }' | g++ -D_GNU_SOURCE -x c++ - -S -o /dev/null -O2
    <stdin>: In function 'void f()':
    <stdin>:3:41: error: invalid conversion from 'kern_return_t {aka int}' to 
'error_t {aka __error_t_codes}' [-fpermissive]

That is, for Mach API calls such as thread_get_state, their return type
"kern_return_t {aka int}" can't be assigned to (our) error_t type.

The Hurd uses its own "typedef enum __error_t_codes error_t;"
([glibc]/sysdeps/mach/hurd/bits/errno.h), contrary to the default
"typedef int error_t;" ([glibc]/stdlib/errno.h).

Another (inconclusive) discussion thread starts at
<https://sourceware.org/ml/libc-alpha/2008-05/msg00123.html>, and if I
understand Roland's messages correctly, he has concerns with now changing
the error_t type (for __cplusplus), for compatibility reasons.

Instead of "error_t err = (error_t) thread_get_state([...])", I guess
I'll change such GDB code to plain "int err".

Roland, do you still veto against patches such as Samuel's


reply via email to

[Prev in Thread] Current Thread [Next in Thread]