Re: Transitioning libgomp from C to C++ implementation

Hi Arsen,

On 08/05/2026 19:06, Arsen Arsenović wrote:
> Christopher Bazley <[email protected]> writes:
> 
>> I haven't worked on libgomp, but I agree with Martin's points.
>>
>> A lot of compilers can plausibly support modern C that will never
>> support modern C++.
> 
> libgomp is a GCC runtime library.  The only compiler of concern is GCC.
> 
>> Modern C offers features for convenience (e.g. auto) and macro-based
>> polymorphism (e.g. _Generic). Subtype polymorphism is more limited
>> than in C++ but still achievable with a reasonable degree of type
>> safety.
> 
> Yet, it offers no destructors, and no move semantics, which are arguably
> the most important features of C++11 and onwards.  I'd trade _Generic
> for those two, and make it out of the deal like a bandit.

OK. If that's what libgomp needs, then that's what makes sense. If what 
libgomp needed were ad hoc polymorphism, then _Generic would be 
perfectly adequate.

>> The issue with malloc seems to me like a canary in the coal mine. I
>> don't know whether libgomp makes significant use of callback functions
>> and event handlers, but they are likely to suffer from similar
>> issues. If the return type of malloc is perceived to be a problem,
>> then it is trivial to write a wrapper macro, e.g.
> 
> I don't see what issue that is.  Previously, allocation and
> initialization were separate.  They aren't in C++.  I don't see how that
> could apply to either callbacks or event handlers.

Callbacks and event handlers commonly have a parameter of type 'void *'. 
Requiring arguments of that type to be explicitly cast to some other 
pointer type makes source code harder to read and write, and actually 
detracts from type safety.

> (Note that every single instance of an allocation in libgomp falls under
>   the case of trivial initialization by merit of being a C codebase, and
>   ergo, even the initially-proposed mechanical conversion of allocation
>   sites is not incorrect, just presumably inconsistent with newer code)
> 
>> C projects 'upgraded' to C++ can end up worse than reasonable code
>> written from scratch according to good idioms of either language, due
>> to:
> 
> Yes, this isn't surprising.  That's exactly why I was arguing not to do
> mechanical explicit void* casts in the cases where memcpy is immediately
> followed by initialization.
> 
> The instances where allocating uninitialized memory is genuinely useful
> are in the tiny minority, but they do exist in libgomp.  These need to
> still call malloc explicitly with a computed size, as in C.
> 
> There are also a number of useful flexible array members, but for these,
> each such type can provide an allocation-and-construction helper.
> 
>> - C++'s overly strict type rules concerning void *. Without care, C++'s type
>>    system has the ironic effect of making code *less* type-safe. (For the same
>>    reason that it would be less type-safe for MyPy to require explicit
>>   conversion of 'Any' to some other type.)
> 
> ?  Those rules aren't overly strict.  I don't follow how this analogy
> with 'Any' demonstrates a lowering of type safety.

Casting discards type information. Preventing implicit conversion of 
type 'void *' to other pointer types on assignment or initialisation 
prevents the compiler from checking that qualifiers weren't discarded, 
or even that the expression whose type is being cast actually has a 
pointer type.

For example:

void callback(const void *p)
{
   int *q = (int *)p; // whoops!
   *q = 1;
}

void callback(long int p)
{
   int *q = (int *)p; // whoops!
   *q = 1;
}

I believe that the concept of any-type (as expressed via void *) is 
orthogonal to the concept of qualified type or subtype. Python's 
treatment of the type annotation Any supports this point of view.

This flaw in the design of C++ is also what necessitated the invention 
of nullptr, which would otherwise be unnecessary. Had the purpose of 
'void *' not been misunderstood, nullptr could simply have been defined 
as a macro: ((void *)0).

>> - C++ constructors being unable to return a failure indication, and the
>>    gymnastics required to work around that without using exceptions (leading to
>>   many identically-named construction helpers).
> 
> I've been writing C++ in places where exceptions would be inconvenient
> for many years now, and this is a fairly infrequent requirement IME.
> 
> It will be fine.

Sorry but I'm not sure what you mean here.

Are you saying that wanting to return a failure indication is 
infrequent, that doing without exceptions is infrequent, or both? I 
guess it depends what kind of code you are writing and what kind of 
system it runs on.

Nowadays a lot of programmers would claim that malloc cannot fail, or at 
least that programs have no need to recover gracefully if it does fail. 
That does not apply to interactive programs running on operating systems 
that do not overcommit memory, but it might apply to non-interactive 
programs running on such systems.

>> - Erasure of designated initialisers that were vital for keeping the code
>>    readable and maintainable (by preventing definitions, for example array
>>   initialisers and enumerations, from diverging).
> 
> Designated initializers exist in C++.

Not usefully, as far as I can tell: https://godbolt.org/z/7j6fdqzrb
I find it frustrating that C++ lags more than a quarter of a century 
behind C in this respect. (I am aware why C++ does not allow arbitrary 
order of initialisers, but I do not see that as a point in its favour: 
debugging a mess caused by misordered  constructor and destructor 
invocations is not fun.)

>> - Gratuitous loss of the ability to find method definitions and usages using
>>    simple tools like 'grep'. (I do not mean gratuitous as a perjorative but in
>>    the specific sense that some useful patterns require subtype polymorphism, in
>>    which case the equivalent C code would have the same issue, but most code
>>   does not.)
> 
> There's no C pattern that is impossible in C++.  There's certainly
> nothing that requires dynamic dispatch that wouldn't require a
> (hand-rolled) vtable in C.

The issue is not impossibility but reduced maintainability of code that 
has fewer unique identifiers. It's possible to similarly reduce the 
maintainability of C programs by using structs to implement namespaces, 
and invoking functions via members. Most C programmers consider that the 
downsides outweigh any advantages.

> Do note, however, that such a table exists in libgomp already:
> https://gcc.gnu.org/cgit/gcc/tree/libgomp/libgomp.h#n1391
> 
>> As I said, I'm not familiar with libgomp, so I have no idea how much
>> it might benefit in areas where C++ truly does excel, such as object
>> lifetime management. In my experience, few C projects have complex
>> object lifetimes (by design), but maybe libgomp is one of them.
> 
> Trivial objects still benefit from destructors.  unique_ptr is a
> distilled example.
> 
>> Lastly, some C programmers are put off contributing to C++
>> codebases. I don't know how common the converse is.
> 
> Given that gcc is already in C++, it seems that that bridge was burned.

It isn't as black and white as that. I know of at least one programmer 
who contributes to GCC because GCC is still largely written in the style 
of a C program, but does not feel inclined or able to contribute to 
Clang. He is probably unusual in that he is outspoken in his opinions.

> Have a lovely day.

You too.
-- 
Christopher Bazley
Staff Software Engineer, GNU Tools Team.
Arm Ltd, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK.
http://www.arm.com/