Pass D const pointer to opaque C library: Guarantees? Optimization-safe?

SimonN eiderdaus at gmail.com
Sat Dec 16 12:36:45 UTC 2017


On Saturday, 16 December 2017 at 11:19:36 UTC, Mike Parker wrote:
> that's a binding, not a wrapper.

Right!

> Not sure what you mean by "safe"
> you only want to prevent changes on the D side and don't care
> if they happen on the C side, then that's fine.

This, yes. I'd like const-annotated D code because of the static 
checks, without risking bugs from aggressive compiler 
assumptions. It's fine it the C side mutates privately.

I am ready to take responsibility in case I misjudge whether one 
of the C functions mutates  detectable state or not.

>> Question 2. If yes, can the wrapper sanely declare foo(const 
>> A*) instead of foo(A*)?
> if you pass immutable variables to the function -- if the
> parameter is const even when the function modifies the
> variable, D will allow immutable to be passed and you're
> looking at unexpected behavior.

This is the heart of the problem, I've overlooked this.

None of my A are immutable, but declaring the bindings as 
foo(const A*) would take immutables.

> I would expect SiegeLord to reject such a PR.
> Only add const to parameters in C function declarations if
> the C API actually declares those parameters as const.

That was my hunch, too. I've asked upstream on the Allegro 
forums. It would be a drastic change, I'd wager there won't be 
any const in the API anytime soon. But I'll give them the due 
time to decide.

If no const C API, I'd stick to private wrappers around 
DAllegro5, with a codebase-wide rule to not pass immutable.

> In principle, I disagree with him
> how much weight should be assigned to "probably".

Hmm, SiegeLord is a core Allegro 5 developer, he could judge 
overriding the C API's promises. But I share your sentiment that 
the public C API should have the final word.

Many thanks for the high-quality answer!

-- Simon


More information about the Digitalmars-d-learn mailing list