[Issue 24793] Allow implicit conversion of const pointers to void*

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Nov 21 21:47:34 UTC 2024


https://issues.dlang.org/show_bug.cgi?id=24793

Richard (Rikki) Andrew Cattermole <alphaglosined at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alphaglosined at gmail.com

--- Comment #7 from Richard (Rikki) Andrew Cattermole <alphaglosined at gmail.com> ---
(In reply to Nick Treleaven from comment #6)
> comment 4:
> > we're risking memory safety issues with stuff like this with the introduction of language features such as placement new.
> 
> Surely passing a `void*` to placement new is not going to be @safe anyway.

When I made my comment in the other ticket, it was not mentioned in the DIP.

It was important to note because we have been relying on language features such
as it, not existing.

> comment 5:
> > Unless that function checks the validity of `p` at runtime, that's not a safe interface
> 
> True. But there is value in @system code of const(void*) not converting to
> void* - that is useful with some C APIs. GLib uses const void* parameters
> (aliased as gconstpointer) here:
> https://docs.gtk.org/glib/callback.CompareFunc.html.
> 
> So perhaps explicit casting of a const T* to a void* should be @safe,
> because safe D can't mutate the pointee byte(s). But I don't think it should
> be implicitly allowed.

I'm on the side of void* shouldn't be able to cast to in @safe at all (unless
going straight to size_t). The entry point of memory unsafetyness should not be
in a @safe function. @trusted sure, but not @safe.

--


More information about the Digitalmars-d-bugs mailing list