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