Re: usage of reserved C++-keyword in cthreads.h
Ulrich Eckhardt <doomster@knuut.de> writes:
> Summary of problems:
> A) In some inlined functions, pointers where cast to void* before being
> assigned to a somestruct*. I wonder why the cast to void*? I admit that I
> didn't check what exact type they where before, but doesn't it work just the
> same and is clearer to directly cast them to somestruct* ?
> C++ refuses implicit type-conversions that are not safe and this doesn't
> compile therefore.
The C++ meaning of 'void' and the C meaning of 'void' are not
compatible with each other.
I'm not sure exactly which casts you are talking about here; I might
be able to comment if you could give a more specific citation.
> B) There was one case (in cthreads.h) where 'catch' was used as identifier,
> additionally, there where quite some cases where 'class' was used (in
> ports.h).
Right--legal C identifiers
> C) While not important for using the headers, I found local
> functions in some C-files. In fact I first triple-checked that that
> was really the case, because I thought that local functions where
> forbidden in C as in C++. Can someone clarify me if that is rather
> new and standard C?
It's a new feature in GCC that is extensively used in Hurd and
Hurd-related libc code.
> D) trivfs uses some hook-function-pointers that the user can set to
> their own functions. I have been trying for an hour or so to get the
> right syntax for one of those but failed. I still don't understand
> the error-messages g++ gave me if necessary, I will provide more
> facts later, I don't have the GNU/Hurd grazing on my LAN currently.
Can you give a specific example? I can't help you with what C++
syntax is supposed to match, but I can certainly explain the C
declarations.
I certainly would not assume that C++ has not changed the meaning of
some more complicated function declarators too.
> E) There where some casts from int to an enumeration. Again, C++ requires
> those to be done explicitly.
Not a bug in C.
> To be honest, I underestimated the amount of changes it takes to
> postincrement the C-headers. Maybe the proposal from Kimmo K. I. Surakka
> might be a better start. However, as he already said, this doesn't solve
> implicit conversions of void* or enum.
> Pondering over that, I just started to wonder if one couldn't #pragma the
> compiler to do what one wants, any gcc-expert here ?
Ah, well, a useful feature might be a syntax for C++ that said "the
following code is C code, not C++ code" and did the right thing
pervasively. But that feature does not exist.
I think you can now see why merely removing "class" from ports.h and
"catch" from cthreads.h is not the only change you'd be requesting.
Making the headers work with C++ might even be a pervasive and ongoing
maintenance hassle.
Thomas
Reply to: