# Why cglobal() in BigInt finalizer?

**URL:** <https://discourse.julialang.org/t/why-cglobal-in-bigint-finalizer/50740>\
**Category:** Internals & Design\
**Created:** [November 25, 2020, 10:48am UTC](https://discourse.julialang.org/t/why-cglobal-in-bigint-finalizer/50740 "2020-11-25T10:48:44Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mikhail\_Kagalenko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikhail_kagalenko/32/13257_2.png) [@Mikhail\_Kagalenko](https://discourse.julialang.org/u/Mikhail_Kagalenko)\
**Post date:** [November 25, 2020, 10:48am UTC](https://discourse.julialang.org/t/why-cglobal-in-bigint-finalizer/50740/1 "2020-11-25T10:48:44Z")

</div>

Looking at gmp.jl source, I noticed that the finalizer in BigInt definition uses `cglobal` to get the (I assume) function pointer:

```julia
function BigInt(; nbits::Integer=0)
        b = MPZ.init2!(new(), nbits)
        finalizer(cglobal((:__gmpz_clear, :libgmp)), b)
        return b
    end

```

Why not use a `ccall()` or `dlsym()` there? What is the reasoning?

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [November 25, 2020, 11:13am UTC](https://discourse.julialang.org/t/why-cglobal-in-bigint-finalizer/50740/2 "2020-11-25T11:13:05Z")

</div>

\_\_gmpz\_clear is a #defined alias for mpz\_clear, which is a function: `void mpz_clear (mpz_ptr);`

However, when `finalizer` is called, it is called to register a finalization routine with (here `b`). It would be incorrect to call the finalization function here, so `ccall` is inappropriate.

`cglobal` Obtain a pointer to a global variable in a C-exported shared library, specified exactly as in ccall [this is the `(:__gmpz_clear, :libgmp)` part]. Returns a Ptr{Type}, defaulting to Ptr{Cvoid} if no Type argument is supplied.

The values can be read or written by unsafe\_load or unsafe\_store!, respectively [this is what we need to be stored as the finalizers’ information, because we need to load the ptr before calling the pointed\_to\_function – why, to keep garbage control doing the right thing, see: [Essentials · The Julia Language](https://docs.julialang.org/en/v1.6-dev/base/base/#Base.GC.@preserve).

---

<div class="post-metadata">

**Author:** ![Mikhail\_Kagalenko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mikhail_kagalenko/32/13257_2.png) [@Mikhail\_Kagalenko](https://discourse.julialang.org/u/Mikhail_Kagalenko)\
**Post date:** [November 25, 2020, 12:09pm UTC](https://discourse.julialang.org/t/why-cglobal-in-bigint-finalizer/50740/3 "2020-11-25T12:09:16Z")

</div>

> [@JeffreySarnoff](#):
>
> It would be incorrect to call the finalization function here, so `ccall` is inappropriate

Of course, it is inappropriate to _call_ `gmpz_clear()` here, but why not pass to the finalizer the  
anonymous function

`x->ccall((:__gmpz_clear, :libgmp), Cvoid, (Ref{Mpz ,), x)` ?

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [November 25, 2020, 12:50pm UTC](https://discourse.julialang.org/t/why-cglobal-in-bigint-finalizer/50740/4 "2020-11-25T12:50:59Z")

</div>

How would that be better?  
also look at the **init** function in gmp.jl, part of it is

```julia
ccall((:__gmp_set_memory_functions, :libgmp), Cvoid,
         (Ptr{Cvoid},Ptr{Cvoid},Ptr{Cvoid}),
         cglobal(:jl_gc_counted_malloc),
         cglobal(:jl_gc_counted_realloc_with_old_size),
         cglobal(:jl_gc_counted_free_with_size))

```

The use of `cglobal` is consistent with the initialization of the memory functions. That is a good reason to use it in registering the finalizer (precludes some potentially inadvertent logical errors from occuring).