error_t, E*, and c++

Hello,

The following can not compile with g++ on GNU/Hurd:

#include <errno.h>
int main(void) {
error_t = EPERM;
}

test.c:9: error: invalid conversion from 'int' to 'error_t'

That is because errno.h #defines EPERM to _HURD_ERRN(1), and then g++
complains because error_t is an enum.

I guess we should for instance make all the #defines #ifndef __cplusplus?

Samuel

Samuel Thibault, le Tue 27 May 2008 11:01:29 +0100, a :
Roland McGrath, le Mon 26 May 2008 20:01:17 -0700, a :
But I think we might just have to live with
C++ using (error_t) EF,

A friend of mine suggested to rather use error_t(EF), which is a bit
less dirty but still works.

(and it makes sense, as the standard says that E* are just ints).

Samuel

Roland McGrath, le Mon 26 May 2008 20:01:17 -0700, a :
(The error_t usage being broken in C++ is at least not a silent change
or breakage of something that already works.)

True for us, but it does work on e.g. Linux since error_t is typedefed
to int there :/

It may also be a problem in some other C++ way I'm not aware of off
hand, for the type of EF not to be int.

I'm open to suggestions. But I think we might just have to live with
C++ using (error_t) EF, or else supply a C++ <errnoor whatever where
there is explicitly no expectation of int-valued or cpp-usable values,
if people would actually use that.

, so that means we have to raise the issue at the C++ language level :/

Thanks,
Samuel

Roland McGrath, le Mon 26 May 2008 20:01:17 -0700, a :
But I think we might just have to live with
C++ using (error_t) EF,

A friend of mine suggested to rather use error_t(EF), which is a bit
less dirty but still works.

or else supply a C++ <errnoor whatever where there is explicitly
no expectation of int-valued or cpp-usable values, if people would
actually use that.

That would be less easy to get accepted I guess.

Samuel

Hmm. You need at least "#define EF EF" to make "#ifdef EF" work.
But one of the reasons for the current style of definition is in
particular so that "#if EAGAIN != EWULDBLCK" works right. That can
only win if it's a cpp-interpretable expression, which cannot use enum
constants or syntax like casts. (The cpp rules mean that the enum
constants are unknown identifiers and treated as zero, so any EF ==
EBAR comparison says they are equal.) I am hesitant to risk breaking
any such #if expressions now compiled in C++ on Hurd. (The error_t
usage being broken in C++ is at least not a silent change or breakage of
something that already works.)

It may also be a problem in some other C++ way I'm not aware of off
hand, for the type of EF not to be int.

I'm open to suggestions. But I think we might just have to live with
C++ using (error_t) EF, or else supply a C++ <errnoor whatever where
there is explicitly no expectation of int-valued or cpp-usable values,
if people would actually use that.


Thanks,
Roland