►
From YouTube: RustFest Zürich 2017 - Mistakes to avoid when writing a wrapper around a C library by Pierre Krieger
Description
Do you need to perform a certain task in Rust? Why not pick a mature C library that already does what you want, and write a wrapping library around it?
Writing a wrapping library is sometimes not as easy as one could think, and you will probably make mistakes that will make you lose time or even make your wrapper unsound.
This talk will show you the most common safety problems you may not have thought of, such as leak safety, but will also give you advices on what not to do when designing the API of your library.
About Pierre Krieger:
After coding in C++ for about ten years, Pierre switched to Rust in 2014 and has been maintaining several game-development-related libraries. He specializes in graphics programming.
A
A
But
before
getting
started,
let's
define
what
a
wrapper
is,
so
the
idea
is
that
a
wrapper
is
simply
a
regular
rest
diary,
but
that
acts
as
a
bridge
between
rust
and
C,
which
are
two
different
word
rust,
is
safe
and
C
is
unsafe.
Rust,
rust
and
C
have
different
kind
of
api's.
The
wrapper
is
here
to
make
a
bridge
between
the
two,
but
writing
a
wrapper
is
not
an
easy
task
and
and
can
be
very
difficult
because
of
the
differences
between
two
languages.
So
here
are,
and
these
differences
can
introduce
mistakes
in
your
code.
A
So
here
are
the
biggest
mistakes
or
not
the
biggest,
but
most
common
mistakes
I
see
in
Ivor
is
in
the
ecosystem.
Mistake
number
9
not
catching
rust,
panics
within
fallbacks
code
by
C
library.
So
when
you
see
library
uses
a
callback
based
design,
so
your
register
a
callback
and
this
callback
caused
our
rest
function.
One
thing
that
can
be
easy
to
forget
is
that
the
C
language
is
not
capable
of
handling
rust
panics,
so
the
code
here
is
dangerous,
because
if
user-provided
function
that
may
panic
actually
panics,
then
bad
things
are
going
to
happen.
A
The
stock
is
going
to
unwind
into
C
code
and
everything
is
going
to
fall
apart
and
probably
crush.
Instead,
you
always
have
to
use
the
catch
and
win
function
which
was
introduced
this
morning
by
the
way,
it's
good
coincidence,
as
always
wrap.
Your
rest
code
are
on
our
own
catch
n,
winds
and
handover
result.
I
was
asked
earlier
today
how
you
are
supposed
to
handle
errors
in
these
situations,
and
it
really
depends
on
the
sitar.
We
sometimes
you
just
need
to
abort.
You
have
no
real
choice.
A
Okay,
mistake
number
ain't,
not
testing
your
rapper
on
a
large
scale,
so
that's
obviously
more
easily
said
and
done,
but
yeah,
but
I
really
advise
you
to
write
at
the
same
time.
At
the
same
time,
your
rapper
and
a
large
scale
project
that
actually
uses
your
rapper
and
that's
very
useful,
because
it's
going
to
let
you
find
flows
in
your
API
things.
You
didn't
necessary,
you
didn't
necessarily
think
about
and
talks.
It
also
acts
as
a
giant
test
suit.
A
Of
course,
that's
not
very
proof,
but
if
it
doesn't
work
at
least
you
know
you
have
a
problem,
so
it's
kind
of
a
giant
astute
mistake,
number
seven,
assuming
that
structs
and
enums
have
a
certain
layout.
So,
for
example,
in
the
code
at
the
top,
you
have
a
strict,
strict
name
foo
with
two
fields
in
a
and
b.a
you
eight
and
you
thirty-two,
and
the
mistake
here
would
be
to
assume
that
bean
comes
after
eight
in
memory
while
in
reality
it's
not
necessarily
the
case.
A
The
compiler
is
free
to
optimize
just
layout
of
its
tracks,
as
it
wishes
so
I
think
I'm,
not
sure
that
I
think.
But
right
now,
it's
not
the
case
right
now.
The
compiler
isn't
going
to
optimize
anything,
but
it
could
be
the
case
in
the
future
anyway,
if
that's
not
the
case
yet
I'm,
not
sure.
Actually,
so,
if
you
want
to
be
to
be
bulletproof
here,
you
should
not
assume
that
D
comes
after
eighteen
memory.
A
If
you
really
need-
or
if
you
need
to
ensure
that
being
actually
comes
after
eight,
you
have
to
use
rep
receipt
annotation
and
that
forces
the
layout.
Similarly,
something
that's,
you
can
sometimes
sign
in
rust.
Libraries,
that's
not
necessarily
related
to
see
libraries,
but
that's
also.
A
problem
in
general
is
when
people
transmute
between
arrays
and
tuples,
but
that's
actually
we're
dangerous,
because
for
the
same
reason
as
I
just
explained,
the
compiler
does
not
necessarily
put
two
elements
of
a
tuple
right
next
to
each
other,
even
for
right.
A
Now
it's
the
case
for
that
I'm
sure
right
now,
it's
the
case,
but
it's
not
totally
sure
that
it's
going
to
be
always
the
case.
So
don't
do
that
mistake,
number
six
trying
to
write
a
high
level
abstraction
first.
So
in
this
example
code
you
have
a
create
objects,
function,
I
put
it
in
an
external
blog
to
show
that
it
represents
the
API
of
C
library.
So
the
C
library
provides
a
function
in
create
objects
which
take
an
array,
s
parameter
in
the
form
of
a
pointer
and
a
number
of
elements
and
I
inverted.
B
A
Is
a
pointer
first
but
whatever
and
the
create
object,
function,
create
objects.
Function,
creates
a
number
of
objects
equal
to
new
objects,
but
since
you're
trying
to
provide
a
nice
API
over
this
in
rust,
what
you
do
is
create
a
type
named
object,
a
struct
which
wraps
around
the
concept
of
an
object,
and
you
provide
a
function
mu
which
calls
create
objects
and
only
creates
one
object.
Because
that's
what
people
we
do
most
of
the
time
and
that's
what's
convenient.
A
You
have
to
solution
to
handle
this
issue
either.
You
say
I'm
too
lazy
to
fix
this
or
you
take
a
lot
of
time
to
rewrite
your
library.
Of
course
here.
Is
it
simple?
It's
a
simple
situation.
So
it's
not
going
to
take
a
lot
of
the
time
to
fix
this,
but
in
a
real,
large-scale
wrapper.
It's
going
to
take
a
lot
of
time,
the
so,
by
the
way,
that's
a
bit
caricatural
in
reality,
you
shouldn't
hesitate
about
open
issues.
Do
not
think
that
complaining.
A
Usually
he
is,
do
not
think
that
it's
annoying
to
open
issue,
it's
better.
To
have
too
many
issues
when
to
view
what
I
advise
you
to
do
is
first
write
an
API,
but
is
as
close
to
Bercy
library
as
possible,
but
by
but
still
remain
safe,
while
doing
so
you're
out
your
IP
I
should
still
be
safe,
but
it
should
be
as
close
to
the
C
API
as
possible.
So
in
the
example
here
here
result
here
is
all
here
is
how
you
fix
this.
You
first
write
a
create
object
as
a
pointer
here.
A
Whatever
you
first
write,
a
create
objects,
rather
a
wrapper
on
create
objects,
but
directly
calls
the
C
function,
create
objects
that
can
return
any
number
of
objects
as
an
indeed
and
then
on
top
of
create
objects.
You
add
another
function
in
foo
which
creates
Y,
which
creates
one
object.
So
you
have
a,
but
the
best
of
both
worlds.
People
who
need
to
create
thousands
of
objects
at
work
at
once
can
simply
call
create
objects
and
most
people
who
are
just
looking
for
a
convenient
API.
A
We
just
call
new,
but
what
I
advise
you
is
to
first
write,
create
objects,
first,
write
a
wrapper
around
create
objects,
and
then
only
you
call
new
and
then
later,
if
needed,
you
can
always
optimize
new
to
be
more
efficient.
If
that's
needed
mistake,
number
five
ignoring
the
problem
of
leak
safety
and
we're
going
to
play
a
little
game,
try
to
spot
the
problem.
A
So
here
is
from
here
on
it's
going
to
get
a
big
more
trickier,
so
we
have
a
capi
represented
by
the
external
block.
The
C
API
provides
an
object
named
foo,
which
I
didn't
show
here.
For
the
sake
of
being
a
brief,
and
there
are
three
functions:
one
function
to
lock
a
foo
one
function
to
unlock
it
once
it's
locked
and
one
function
named,
do
something
which
must
not
be
used.
Waifu
is
locked,
that's
what
the
c
library
says
do
not
call
do
something.
A
What
wild
of
who
is
locked
because
I
don't
handle
that
and
your
rust
wrapper,
that
your
attack
that
you're
writing,
provides
a
wrapper
around
the
concept
of
a
foo
which
I
named
here.
Foo
brother.
It
provides
two
function.
Two
functions
do
something
unlock
which
simply
call
the
c
functions
directly.
They
just
cover
c
functions
directly,
except
that
the
lock
function
returns.
A
guard
objects
if
you're
familiar
with
the
concept
of
AII
in
c++.
That's
exactly
the
same
principle.
A
A
A
So
the
lock
object
at
the
bottom
here
and
then,
while
the
lock
object
is
alive,
you
cannot
call
do
something,
because
the
lock
object
has
an
exclusive
burrow
of
the
foo
and
do
something
also
needs
an
x,
^
foo
and
you
can't
have
two
exclusive
burrow,
so
you
get
a
compilation
error.
So
that's
that's
the
intent
of
these
API,
that's
what
this
API
is
trying
to
do,
and
it's
quite
nice.
You
think
you,
you
ain't
sure
at
compile
time,
but
you
cannot
call
do
something
while
the
foo
is
lock.
A
That's
quite
nice,
but
actually
this
is
unsafe
because
you
can
actually
bypass
the
burrow.
You
can
simply
call,
as
shown
in
the
second
block
of
code.
You
can
simply
call
man
forget
on
the
lock
and
the
foo
is
actually
going
to
stay
locked,
while
your
lock
variable
disappears
and
then
the
user
will
be
able
to
call
do
something.
Even
verbal
foo
is
still
locked
and
you're
very
you're,
violating
the
rules
of
the
capi
wrapping
around
and
that's
really
just
bad.
A
A
It's
a
famous
event
at
the
time
of
1.0
kalique
apocalypse
and
how
you
fix
this
problem
in
your
wrapper
is
by
using
a
technique
named
pre
pooping,
your
pants.
So
that's,
that's
not
I
didn't
name
that
myself.
So
someone
came
up
with
a
name
and
I
mentioned
this
name
here,
so
you
can
google
it,
but
I
recommend
googling,
rust-free,
popping
offense
and
not
just
recruiting
events.
That's
my
suggestion.
A
So
the
idea
here
to
fix
this
is
that
you
need
a
second
field
in
your
foo
wrapper
that
contains
whether
or
not
befool
is
currently
locked.
So
when
you
call
do
some,
when
your
user
calls
do
something
or
lock,
you
first
have
to
check
at
run
time
whether
the
variable
contains
you
need
to
ensure
that
is
locked
variable
field
in
sports,
overwise
you're
violating
the
C
API
and
in
the
drop
in
the
destructor
of
lock.
Your
right
force
is
in
your
right
force
in
is
locked
and
but
what
add?
A
That
adds
a
small
runtime
overhead,
but
unfortunately,
there's
no
real
choice
here.
Mistake
number,
four,
forgetting
about
hidden
global
variables,
I'm
going
to
take,
for
example,
of
open,
Yale
open
a
L
sound
driver
here,
because
it's
really
representative.
So
the
way
you
use
open
in
your
library
is
you
first
create
what
is
called
a
context.
We've
functioned
that
a
dinner
show
here,
which
is
called
a
se,
create
context
or
whatever.
It's
not
the
point
here.
A
When
you
call
a
scenic
context,
current,
what
you're
essentially
doing
is
just
set
the
value
of
this
global
variable,
and
this
design
is
really
not
fret
safe
at
all,
because
if
you
have
two
threads
that
are
trying
to
use
open,
yellow,
say
time
well,
Fred
one
calls
a
seam
in
context
current
and
some
open
a
year
staff
fred
to
cause
a
scene,
a
context,
currents,
wire,
fred,
one
is
running
and
it
will
modify
the
behavior
of
red
one
and
that's
bad
and
that's
really
fred
unsafe.
So
you
may
think.
A
But
what
if
I
use
a
new
text
and
that's
the
solution,
people
can
come
up
with.
So
that's
the
code
here
is
what
you
would
put
in
your
wrapper.
You
create
a
new
text
named
current
context,
new
text,
a
static
mutex,
and
whenever
you
want
to
do
something
with
open
air,
you
first
lock
the
new
text
and
then
on
inequal.
Yes,
you
made
contacts
current.
A
A
Unfortunately,
it
doesn't
work.
Why?
Because,
if
you
create
a
project
named
project
which
uses
two
dependencies
open,
al
you're,
opening
a
wrapper
and
no
a
third-party
dependency
named
over
some
library
and
this
third-party
library
uses
open,
ear,
open,
ear
wrapper
as
well,
but
a
different
version.
What
cargo
is
going
to
do
in
this
situation
here,
I
showed
you
a
small
dependency
graph.
A
So
if
you
try
to
use
open
air
wrapper
and
over
sound
library
at
the
same
times
in
two
different
threads,
but
we
each
lock
the
own
version
of
the
mutex
and
they
will
conflict
with
each
other.
So
you
know
you
can't
do
that
and
the
problem
here,
as
my
conclusion,
is
that
there's
just
no
solution
openly
I
can
unfortunately
not
be
wrapped
around
safely
or
if
you
have
an
idea.
Let
me
know
because
I
already
have
okay.
We
can
talk
later.
A
If
you
have
an
idea
of
our
examples
of
similar
impossible
ap
is
our
X
deep
because
of
a
function
in
exit,
Handler
and
I
actually
have
a
wrapper
on
X.
Leave
myself
and
I
know
it's
unsafe,
but
I
really
have
no
choice,
get
end
and
because
you're
not
going
to
say
screw
X
leave
just
because
of
this.
Unfortunately,
it
has
too
much
market
last
year.
A
Yeah
get
in
one
set
and
also
unsafe
cannot
be
wrapped
on
safety,
but
fortunately,
since
the
STD
wraps
around
it-
and
you
can
only
have
one
version
of
STI
live
in
any
given
executable,
then
it's
safe.
Actually,
our
example
of
API
is
what
are
problematic,
but
also
have
a
global
kind
of
global
variable
in
thing
OpenGL,
several
api's
from
the
Windows
operating
system.
A
They
both
have
constable.
Let
you
set
properties
for
the
current
thread,
so
you
have
to
have
spawn
a
background
thread
when
you
who
want
to
do
stuff.
That's
also
our
runtime
overhead,
but
you
have
no
choice
and
other
libraries
that
have
a
global
initialization
function.
You
have
to
take
care
of
initialization
and
the
initialization
functions
are
reference
counted?
If
you
call
the
initialize,
while
something
else
is
using
your
library
when
it's
bad,
it's
tech
number
free
reading,
primitives
from
memory
without
checking,
so
it
concerns
three
different
things:
floating
points,
booze
and
cars.
A
So
rest
specifications
of
rest
say
that
boolean's
must
on
account
must
represent
the
memory.
Representation
of
boolean
must
always
be
either
1
or
0
of
all
visits
technically
unspecified
with
whatever
memory
pass.
Representation
of
cars
must
always
be
evaded,
unique
on
scalar
value
and
the
memory
representation
of
14
points.
Men
must
never
be
a
signalling
none.
So
if
you
have
memory-
and
you
don't
know
what
it
contains-
it's
dangerous
to
read
a
bull,
a
car
or
a
floating
point
from
it.
You
you
can
judge.
A
You
cannot
just
blindly
read
memory,
because
it's
very
dangerous
and
I
give
some
examples
here
in
the
first
example,
if,
if
uninitialized,
even
an
initialize
function,
returns
something
else
than
0
or
1,
when
you
have
an
in
find
behavior,
and
the
second
example
is
an
and
if
I'm
behavior
as
well
and
of
course
structs
but
are
made
of
booze
cars
and
floating
points
are
also
concerned.
So
how
you
check
this?
For
floating
points
you
use
from
bits
functions
you
first,
you
first
read
an
integer
and
then
you
call
from
bits
on
that
integer.
A
Instead
of
reading
a
pool,
you
also
first
read
an
integer
and
then
check
whether
integer
a
different
is
different
from
0
and
forecast
as
a
function
name
car
from
you
32.
So
you
first
read:
are
you
32
and
when
you
call
this
functions,
this
function
and
B
is
this?
Fourth,
where
these
three
functions
and
comparing
whether
integer
is
different
from
zero?
What
you
should
do
to
ensure
that
you're
actually
doing
something
correct
and
not
undefined
behavior
mistake,
number
two
assuming
the
threat
implementations
are
bug
free
and
this
one
is
really
tricky.
A
So
we're
going
to
sports
we're
going
to
play,
try
to
spot
the
problem
again,
so
the
C
API
that
you're
trying
to
wrap
around
here
again
in
an
external
block.
It's
very
simple
here:
you
have
a
function.
A
c
function
named
foo
which
takes
as
parameter
an
array
array
is
passed
as
a
pointer
and
the
number
of
elements.
If
you
have
ever
done-
and
you
see
in
your
life,
you
probably
familiar
with
that
in
rust.
We
are
trying
to
wrap
around
with
API
with
a
full
wrapper
API.
A
So
since
you're
trying
to
write
a
convenient
API,
you
make
your
flu
wrapper
function,
generic
over
any
type
that
implements
the
ref
to
an
array
of
u8.
So
what
that
means
is
that
array
arc
parameter
can
be
anything
but
represents
an
array.
But
you
you
write
your
wrapper
you're
trying
to
be
convenient,
and
then
you
simply
call
the
C
function,
the
Foo
function.
You
call
as
PTR
and
land
on
your
array
and
you
call
the
fee.
Foo
functions
the
Foo
function
with
these
parameters.
A
Yes,
that's
the
problem,
so
our
problem
here
is
that
since
few
rapper
can
accept
anything,
the
user,
the
user
of
your
library
can
simply
write
malicious
pointer.
So
the
user
of
your
library
writes
malicious
pointer.
It
contains
two
fields
to
vex
and
the
user
implements
the
RF
on
malicious,
pointer
and
half
over
time,
but
the
error
function
is
going
to
read
on
the
first
back
and
half
over
time,
a
second
back
so
you're
betting.
A
A
Let
me
explain
first,
when
you
call
array
arc
dot
as
PTR.
What
happens
in
reality
is
what
you
call
array
arc:
dots,
D,
F,
dot,
PTO
and
when
in
call
array,
our
clan,
what
happens
in
reality
is
you
call
array,
are
dots
the
F
dot
length?
So
what
could
end
up
happening
is
that
you
get
a
function
pointer
to
the
first
back
and
the
length
of
a
second
back
and
then
bad
things
are
going
to
happen,
ouch.
A
So
back
to
a
question.
Why
would
someone
do
that
of?
Obviously
nobody
is
going
to
write
in
malicious
pointer,
but
in
a
real
life
project.
What
could
end
up
happening
is
the
Burg
in
its
right
implementation.
So
that's
obvious,
that's
obviously
a
very
serious
bug,
but
it
could
really
be
a
bug.
Oh
ok,
I
fought.
My
over
side
was
next.
It
could
be
a
real
in
the
DRF
implementation
and
not
intended.
A
So
how
would
you
solve
that?
The
first
solution
is
to
call
the
ref
at
the
start
of
a
function.
So
you
turn
your
array
arc
parameter
into
an
actual
slice
of
you
ate
at
WA.
For
the
first
time.
Does
that
and
the
second
line
calls
the
full
function,
but
sometimes
this
solution
can
be
inconvenient,
so
the
second
solution
is
to
use
a
custom
unsafe
threat,
so
instead
of
requiring
drf
you'll
require
a
trade
name
and
safety
ref,
and
basically
the
burden
of
implementing
the
ref
correctly
is
on
the
user
layer
of
your
library.
A
So
so,
basically,
as
a
writer
of
your
wrapper,
you
only
write
through
brother
and
the
user
of
your
wrapper
has
to
write
in
safety
ref,
for
whatever
they
want-
and
here
are
all
here
are
other
examples
of
threats
which
can
be
dangerous
as
rebel
row,
partial,
a
partial
or
iterator.
If
you
use
a
new
Venus,
for
example,
iterator,
if
a
number
of
elements
return,
if
the
number
of
elements
return
by
size,
size
hint
doesn't
match
actual
number
of
elements
in
the
iterator,
then
it
could
happen.
It
could
actually
be
a
bug.
A
Someone
implements
it
right
on
the
custom
type
and
they
have
a
mismatch
between
what
sizings
returns
and
what
next
returns
so
and
you
had
when
you
write
a
wrapper.
You
have
to
be
aware
of
that.
You,
for
example,
shouldn't
allocate
a
block
of
uninitialized
memory
of
a
certain
number
of
elements
and
then
on
your
and
then
don't
write
any
animal,
because
iterator
is
actually
empty.
So
that's
just
an
example:
I
didn't
really
write
it
as
code
I
just
quickly
went
over
it.
A
If
you
use
any
of
this
thread,
you
have
to
be
aware
of
this
kind
of
problems.
A
mistake
number
one.
So
this
is
an
API
related
mistake
using
lifetimes
for
long-lived
objects.
So
a
very
common
situation
in
C
libraries
is
that
the
C
library,
the
C
library
provides
wavy,
provides
you
with
two
types
of
objects
named
a
and
B
and
says
that
you
must
ensure
that
a
outlives
B
and
a
common
solution,
as
writer
of
a
rudder,
is
to
use
a
lifetime.
A
A
However,
using
a
lifetime
actually
is
more
restrictive
than
just
the
concept
of
outlives.
The
C
API
says
says
that
build
must
out,
if
a
sorry
a
must
out
if
B,
but
a
burrow
is
more
restrictive
than
that
and
the
problem
with
being
wrong
as
to
given
the
restriction
question.
Is
that
the
be
sorry
the
a
must
not
move
in
memory
as
long
as
it's
being
borrowed?
The
consequences
of
that
is
that
someone
trying
to
use
a
wrapper
cannot
put
an
A
and
a
B
both
in
the
same
struct
and
that's
a
problem.
A
A
So
what
I
advise
you
to
do
is
simply
use
only
lifetimes
for
temporary
objects.
The
kind
of
objects
virtue
only
keep
on
the
stack,
so
locks
accessors.
What
I
mean
by
keep
on
the
stack
is
that
at
the
beginning
of
a
function
you
create
an
object
and
then
object
is
drop,
that
we
end
our
function
for
this
kind
of
types
you
can
use
lifetimes,
but
when
you
have
objects
that
leave
for
a
long
time,
do
not
use
lifetimes
and
sell
I
suggest
you
use
arcs
on
our
seas.
That's
also
a
small
runtime
overhead.
A
But
again
it's
I.
Think
in
my
that's
my
personal
opinion,
but
it's
better
than
these
restrictions,
because
users
are
going
to
be
really
confused
about
how
you
to
use
your
API
and
as
a
cop
you
as
a
conclusion,
if
you,
if
you're
writing
a
wraparound
around
the
sea
library,
I
strongly
recommend
that
you
read
the
rest
on
Aamir
Khan,
which
I
put
the
URL
here.
A
If
you
feel
overwhelmed
by
the
safety
related
problems
you
have
to,
you
have
to
be
positive.
Keep
in
mind
that
safe
first
actually
protects
you
against
all
these
problems.
Well,
if
you're
right,
if
you
were
writing
C,
you
would
have
to
deal
with
this
second
thing:
I
advise
you
is
to
take
inspiration
from
the
API
guidelines.
C
A
A
problem
with
I'm
going
to
back
to
this
is
it.
The
problem
is
that
when
you
here
is
the
dependency
graph
of
your
project
in
the
cargo
that
tunnel
of
your
project,
you
only
have
open
air
wrapper
over
sound
library.
You
don't
really
know
which
version
of
open
air
wrapper
is
used
by
over
sound
library.
I
mean
you
can
know
it,
but
it's
not
it's.
None
of
your
concern.
The
person
who
writes
over
sound
library
could
decide
to
burn
the
version
of
open
air
rather
without
notifying
you,
so
you
don't
as
well.
A
A
Yeah
I
see
what
you
mean
you
can
you
can
fix
that
with?
No.
Basically,
if
you
write,
if
you're
the
writer
of
the
open
year
Radford
library,
you
can
ensure
that
people
can
have
two
different
version
of
open,
Yale
library,
of
open
air
wrapper
in
their
project
as
well,
rapper
as
writers
and
I'm
going,
and
getting
this
that
as
the
writer
of
open
air
rapper,
you
can
ensure
that
this
doesn't
happen.
But
if
someone
else
writes
another
open
year
rapper,
then
you
have
the
same
problem.