Re: Transitioning libgomp from C to C++ implementation

On 09/05/2026 14:21, Jonathan Wakely wrote:
> 
> 
> On Sat, 9 May 2026, 09:40 Christopher Bazley via Gcc, <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 
> 
>     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).
> 
> 
> No it couldn't.

Yes, my words misrepresented the order of events.

It is surprising to me that nullptr wasn't invented until C++11, given 
that there were known issues with overloading since the inception of C 
with classes. Those early problems with overloading do appear to stem 
from Stroustrup's redefinition of the semantics of the 'void *' type. I 
stand by that.

The idea of using '0' as a null pointer constant seems so bad to me that 
I can scarcely believe it was standard C++ for so long. That is what led 
to my wrong statement.

> This thread is getting more and more of topic, but defining nullptr as 
> just a void* would not allow the useful property of overloading 
> functions like unique_ptr::operator= on whether the argument is an 
> actual pointer (which would replace the owned pointer, but is disallowed 
> by plain assignment) or is the special nullptr value (which is allowed).
> 
> That is:
> 
> uptr = (void*)0; // error
> uptr = nullptr; // ok

Thanks for the explanation.

I can see that nullptr has some use for template type deduction, 
although based on your description I find that usage questionable. 
Assignments do not generally have different semantics depending on 
whether the assigned expression is a literal or not.

> I think you have an overly simplistic idea of why nullptr was added to 
> C++, leading to an incorrect conclusion about it only being necessary 
> because of C++ pointer conversion rules.

My "overly simplistic idea" was derived from my reading of Stroustrup 
(1994, reprinted 1998), 'The Design and Evolution of C++' (pp 230):

================
A void* cannot be assigned to anything without a cast.  Allowing 
implicit conversions of void* to other pointer types would open a 
serious hole in the type sustem.  One might make a special case for 
(void*)0, but special cases should only be admitted in dire need.  Also, 
C++ usage was determined long before there was an ANSI C standard, and I 
do not want to have any critical part of C++ rely on a macro. 
Consequently, I used plain 0, and that has worked very well over the 
years.  People who insist on a symbolic constant usually defined one of

const int NULL = 0; // or
#define NULL 0

As far as the compiler is concerned, NULL and 0 are then synonymous. 
Unfortunately, so many people have added definitions NULL, NIL, Null, 
null, etc. to their code that providing yet another definition can be 
hazardous.

There is one kind of mistake that is not caught when 0 (however spelled) 
is used for the null pointer.  Consider:

void f(char*);

void g() { f(0); } // calls f(char*)

Now add another f() and the meaning of g() silently changes:

void f(char*);
void f(int);

void g() { f(0); } // calls f(int)

This is an unfortunately side effect of 0 being an int that can be 
promoted to the null pointer, rather than a direct specification of the 
null pointer.  I think a good compiler should warn, but I didn't think 
of that in time for CFront.  Making the call to f(0) ambiguous rather 
than resolving it in favour of f(int) would be feasible, but would 
probably not satisfy the people would want NULL or nil to be magical.
================

What I remembered was Stroustrup's explanation (which I don't find 
particularly compelling) of why C++ did not use (void*)0 as a null 
pointer constant. However, I forgot that his book can't be used directly 
to justify the invention of nullptr, because nullptr hadn't been 
invented when he wrote the book.

> It exists for reasons related to template type deduction and 
> overloading, not because void* isn't convertible to other pointer types.

I don't think nullptr is necessary to resolve the problem with 
overloading that Stroustrup mentioned in his book. Consider his example, 
assuming that NULL is defined as ((void *)0) and assuming that C++ had 
not departed from C's semantics for void *:

void f(char*);

void g() { f(NULL); } // calls f(char*)

But also:

void f(char*);
void f(int);

void g() { f(NULL); } // still calls f(char*)

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