# C pointer not nullified using Intel oneAPI Fortran

**URL:** <https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518>\
**Category:** Help\
**Created:** [March 2, 2024, 3:14am UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518 "2024-03-02T03:14:25Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 2, 2024, 3:14am UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/1 "2024-03-02T03:14:26Z")

</div>

Greetings,

I’ve tripped over a strange issue while testing my [SQLite 3 bindings](https://github.com/interkosmos/fortran-sqlite3) with Intel oneAPI 2024. It boils down to not being able to nullify C pointers. For instance, an SQLite database handle is freed by calling `sqlite3_close(ptr)`. The C pointer `ptr` is passed by value, as SQLite expects `sqlite3 *db`. The pointer itself is therefore never set to `NULL` by SQLite 3:

```fortran
    ! int sqlite3_close(sqlite3 *db)
    function sqlite3_close_(db) bind(c, name='sqlite3_close')
        import :: c_int, c_ptr
        implicit none
        type(c_ptr), intent(in), value :: db
        integer(kind=c_int) :: sqlite3_close_
    end function sqlite3_close_

```

The interface library provides a wrapper which nullifies the pointer after calling the SQLite function:

```fortran
    function sqlite3_close(db)
        type(c_ptr), intent(inout) :: db
        integer :: sqlite3_close

        sqlite3_close = sqlite3_close_(db)
        if (sqlite3_close == SQLITE_OK) db = c_null_ptr
    end function sqlite3_close

```

This works as expected with GNU Fortran 13. But compiling the test program using Intel oneAPI Fortran, `ptr` is never nullified:

```fortran
    ! The wrapper function sets `ptr` to `c_null_ptr` after
    ! calling interface `sqlite3_close_(ptr)`:
    rc = sqlite3_close(ptr)

    ! Output:
    ! "F" - GNU Fortran
    ! "T" - Intel oneAPI Fortran
    print *, c_associated(ptr)

```

The same behaviour can be observed when calling the interface directly:

```fortran
    ! Pass `ptr` by value to SQLite, then nullify:
    rc = sqlite3_close_(ptr)
    ptr = c_null_ptr

    ! Output:
    ! "F" - GNU Fortran
    ! "T" - Intel oneAPI Fortran
    print *, c_associated(ptr)

```

Does anybody know the reason for this?

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 2, 2024, 10:35am UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/2 "2024-03-02T10:35:01Z")

</div>

It looks like maybe one extra instruction found it’s way in that should not be there (?):

> **[Compiler Explorer - Fortran](https://godbolt.org/z/aaWeEafTj)**
>
> subroutine test(ptr)
> use, intrinsic :: iso\_c\_binding
> type(c\_ptr), intent(inout) :: ptr
> 
> interface
> function sqlite3\_close\_(ptr) bind(c)
> import c\_ptr, c\_int
> type(c\_ptr), value :: ptr
> ...

If we look at the gfortran output (essentially identical to ifort and flang):

```txt
test_:
        push rbx ; push existing rbx value to stack
        mov rbx, rdi ; copy the reference to ptr to rbx
        mov rdi, QWORD PTR [rdi] ; copy the value pointed to into rdi
        call sqlite3_close_ ; call sqlite routine with value in rdi
        mov QWORD PTR [rbx], 0 ; set ptr to NULL
        pop rbx ; restore the old value of rbx
        ret

```

But with ifx, there appears to be a superfluous instruction.

```txt
test_:
        push rbx
        mov rbx, rdi
        mov rdi, qword ptr [rdi]
        call sqlite3_close_@PLT
        mov rax, qword ptr [rip + iso_c_binding_mp_c_null_ptr_@GOTPCREL]
        mov rax, qword ptr [rax] ; <----- ???
        mov qword ptr [rbx], rax
        pop rbx
        ret

```

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 2, 2024, 3:17pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/3 "2024-03-02T15:17:30Z")

</div>

Thanks, now, what hath Intel wrought?

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 2, 2024, 3:43pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/4 "2024-03-02T15:43:00Z")

</div>

Is `ptr` a dummy argument?

I have the feeling like the address of an argument, and the pointer that argument contains, are getting mixed-up some how?

This program does not reproduce the behavior you describe (I used `-fno-inline` with ifx to prevent inlining from interfering) :

```fortran
function sqlite3_close_(ptr) bind(c)
    use, intrinsic :: iso_c_binding
    type(c_ptr), value :: ptr
    integer(c_int) :: sqlite3_close_
    sqlite3_close_ = 0
    if (c_associated(ptr)) then
        print *, "Closing database"
    end if
end function

program main
use, intrinsic :: iso_c_binding
implicit none

integer, target :: a = 42
type(c_ptr) :: p_a

p_a = c_loc(a)

call test(p_a)

print *, c_associated(p_a)

contains

subroutine test(ptr)
    use, intrinsic :: iso_c_binding
    implicit none
    type(c_ptr), intent(inout) :: ptr

    interface
        function sqlite3_close_(ptr) bind(c)
            import c_ptr, c_int
            type(c_ptr), value :: ptr
            integer(c_int) :: sqlite3_close_
        end function
    end interface
    integer(c_int) :: rc

    ! Pass `ptr` by value to SQLite, then nullify:
    rc = sqlite3_close_(ptr)
    ptr = c_null_ptr

end subroutine

```

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 2, 2024, 4:46pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/5 "2024-03-02T16:46:09Z")

</div>

The pointer `ptr` may be a dummy argument, but hasn’t to. A minimal example:

```auto
$ cd /tmp/
$ git clone --depth 1 https://github.com/interkosmos/fortran-sqlite3
$ cd fortran-sqlite3/
$ touch demo.f90

```

The example program `demo.f90`:

```fortran
! demo.f90
program main
    use, intrinsic :: iso_c_binding
    use :: sqlite3
    implicit none

    character(len=*), parameter :: DB = ':memory:'
    integer, parameter :: FLAG = ior(SQLITE_OPEN_CREATE, SQLITE_OPEN_READWRITE)

    integer :: rc
    type(c_ptr) :: ptr, stmt

    ptr = c_null_ptr
    stmt = c_null_ptr

    print '("ptr.....: ", L)', c_associated(ptr)
    print '("stmt....: ", L)', c_associated(stmt)

    rc = sqlite3_open_v2(DB, ptr, FLAG)
    print '("open....: ", L)', c_associated(ptr)

    rc = sqlite3_prepare_v2(ptr, 'SELECT sqlite_version()', stmt)
    print '("prepare.: ", L)', c_associated(stmt)

    rc = sqlite3_finalize(stmt)
    print '("finalize: ", L)', c_associated(stmt)

    rc = sqlite3_close(ptr)
    print '("close...: ", L)', c_associated(ptr)
end program main

```

Building with GCC:

```auto
$ make
$ gfortran -o demo demo.f90 libfortran-sqlite3.a -lsqlite3
$ ./demo
ptr.....: F
stmt....: F
open....: T
prepare.: T
finalize: F
close...: F

```

Building with Intel oneAPI:

```auto
$ make clean
$ make CC=icx FC=ifx
$ ifx -o demo demo.f90 libfortran-sqlite3.a -lsqlite3
$ ./demo
ptr.....: F
stmt....: F
open....: T
prepare.: T
finalize: T
close...: T

```

The issue can be seen for `stmt` with `sqlite3_finalize()` as well.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 2, 2024, 5:04pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/6 "2024-03-02T17:04:32Z")

</div>

Does rc always return status ok? 🤔

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 2, 2024, 5:08pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/7 "2024-03-02T17:08:27Z")

</div>

Yes. But SQLite is quite generous, so, it doesn’t mean much.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 2, 2024, 5:21pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/8 "2024-03-02T17:21:04Z")

</div>

> [@interkosmos](#):
>
> `if (sqlite3_close == SQLITE_OK) db = c_null_ptr`

Well it means this part was effectively ignored by ifx, without any doubt on the predicate value. (What you already said.)

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 2, 2024, 5:56pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/9 "2024-03-02T17:56:34Z")

</div>

I‘m starting to think that this is some kind of protection by Intel against memory leaks. Maybe there is a compiler flag to disable it?

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 2, 2024, 6:54pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/10 "2024-03-02T18:54:50Z")

</div>

For the subroutine,

```fortran
subroutine test(ptr)
    use, intrinsic :: iso_c_binding
    type(c_ptr), intent(inout) :: ptr

    interface
        function sqlite3_close_(ptr) bind(c)
            import c_ptr, c_int
            type(c_ptr), value :: ptr
            integer(c_int) :: sqlite3_close_
        end function
    end interface
    integer(c_int) :: rc

    ! Pass `ptr` by value to SQLite, then nullify:
    rc = sqlite3_close_(ptr)
    ptr = c_null_ptr

end subroutine

```

the ifx compiler (`ifx -O2`) generates instructions which resemble the following C code:

```c
// test.c
#include <stdint.h>
#define NULL 0

// --- sqlite3 ---

struct sqlite3_database {
    // ...
};

typedef struct sqlite3_database* sqlite3; // opaque pointer

extern int sqlite3_close(sqlite3 *db);

// --- iso_c_binding ---

typedef void * c_ptr;

struct {
    const intptr_t c_null_ptr;
} iso_c_binding = { NULL };

// --- x86-64 ---

static intptr_t a, b, c, d; // registers

static struct {
   // ...
} stack;

#define pop(s) /* ... */
#define push(s) /* ... */

void test_(c_ptr *ptr) {
        
    push(b); // push rbx
    b = (intptr_t) ptr; // mov rbx, rdi
    d = (intptr_t) *ptr; // mov rdi, qword ptr [rdi]
    a = sqlite3_close((sqlite3 *) d); // call sqlite3_close_@PLT
    a = iso_c_binding.c_null_ptr; // mov rax, qword ptr [rip + iso_c_binding_mp_c_null_ptr_@GOTPCREL]
    a = *((intptr_t *) a); // (???) mov rax, qword ptr [rax] (???)
    *((intptr_t *) b) = a; // mov qword ptr [rbx], rax
    pop(b); // pop rbx
                                           // ret
}

```

When I compile this with `icx -O2`, I get

```txt
test_: # 
        push rax
        mov qword ptr [rip + b], rdi
        mov rdi, qword ptr [rdi]
        call sqlite3_close
        mov rax, qword ptr [rip + iso_c_binding]
        mov rax, qword ptr [rax]
        mov rcx, qword ptr [rip + b]
        mov qword ptr [rcx], rax
        pop rax
        ret
iso_c_binding:
        .zero 8

```

which you can see closely reproduces the `ifx` output of the Fortran routine:

```txt
test_:
        push rbx
        mov rbx, rdi
        mov rdi, qword ptr [rdi]
        call sqlite3_close_@PLT
        mov rax, qword ptr [rip + iso_c_binding_mp_c_null_ptr_@GOTPCREL]
        mov rax, qword ptr [rax]
        mov qword ptr [rbx], rax
        pop rbx
        ret

```

In my eyes at least, the following assignment

```c
    a = *((intptr_t *) a); // (???) mov rax, qword ptr [rax] (???)

```

is superfluous as the register `a` already contains the null pointer value. To me this smells like a bug.

* * *

Try printing the value of `transfer(ptr,1_c_intptr_t)` before and after the `sqlite3_close` function call. I expect the value will be different (which would indicate that this is indeed a bug).

Why would that make no sense? Because in your wrapper,

```auto
    function sqlite3_close(db)
        type(c_ptr), intent(inout) :: db
        integer :: sqlite3_close
        sqlite3_close = sqlite3_close_(db)
        if (sqlite3_close == SQLITE_OK) db = c_null_ptr
    end function sqlite3_close

```

the C procedure takes the argument by value, meaning it can’t change. If the association status is true, before and after the call, and yet the value pointed to by `db` changed before and after, it means there was an illegal change.

---

<div class="post-metadata">

**Author:** ![alirezagh76](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@alirezagh76](https://fortran-lang.discourse.group/u/alirezagh76)\
**Post date:** [March 2, 2024, 8:56pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/11 "2024-03-02T20:56:16Z")

</div>

Probably, a bug in ifx, at some point `c_null_ptr` is not really `NULL` as it must be.

There is a work around:  
instead of using `c_null_ptr` to nullify `c_ptr` variables like

`stmt = c_null_ptr`

you can do as follows:

```auto
real(8), pointer:: a=>null()
stmt = c_loc(a)

```

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 3, 2024, 9:11am UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/12 "2024-03-03T09:11:07Z")

</div>

I just tested your program using a slightly older version of ifx (`ifx (IFORT) 2022.0.0 20211123`), despite recommendations from Intel to upgrade to the latest version (2024.x). The operating system is Ubuntu 20.04.6 LTS.

It seems to works correctly:

```TXT
/tmp/fortran-sqlite3$ make CC=icx FC=ifx
icx -O2 -march=native -c src/sqlite3_macro.c
ifx -O2 -march=native -c src/sqlite3_util.f90
ifx -O2 -march=native -DSQLITE_ENABLE_COLUMN_METADATA=0 -c src/sqlite3.F90
ar rcs libfortran-sqlite3.a sqlite3.o sqlite3_macro.o sqlite3_util.o
/tmp/fortran-sqlite3$ ifx -o demo demo.f90 libfortran-sqlite3.a -lsqlite3
/tmp/fortran-sqlite3$ ./demo 
ptr.....: F
stmt....: F
open....: T
prepare.: T
finalize: F
close...: F

```

I did however get an error at link time,

```txt
$ ifx -o demo demo.f90 libfortran-sqlite3.a -lsqlite3
ld: libfortran-sqlite3.a(sqlite3.o): in function `sqlite3_mp_sqlite3_db_name_':
ifxpk2X4h.i90:(.text+0x2f0): undefined reference to `sqlite3_db_name'

```

so I temporarily commented out this particular function (it was unused anyways). By the looks of it, the SQLite library I installed is missing this particular function.

Looking at the output of compiler explorer, with ifx v2022, the superfluous instruction is not there ⚠ (scroll sideways to see what I mean):

```txt
    ifx 2024.0.0 | ifx 2022.0.0
  1	test_: | test_:
  2 push rbx | push rbx
  3 mov rbx, rdi | mov rbx, rdi
  4 mov rdi, qword ptr [rdi] | mov rdi, qword ptr [rdi]
  5 call sqlite3_close_@PLT | call sqlite3_close_@PLT
  6 mov rax, qword ptr [rip + iso_c_binding_mp_c_null_ptr_@GOTPCREL] | mov qword ptr [rbx], 0
  7 mov rax, qword ptr [rax] | pop rbx
  8 mov qword ptr [rbx], rax | ret
  9 pop rbx
 10 ret

```

If I edit the end of your demo program like this:

```auto
    print *, "before close", transfer(ptr, 1_c_intptr_t)
    rc = sqlite3_close(ptr)
    print '("close...: ", L)', c_associated(ptr)
    print *, "after close ", transfer(ptr, 1_c_intptr_t)

```

The output produced is,

```txt
 before close 25035960
close...: F
 after close 0

```

@interkosmos, can you show what you get on your system?

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 3, 2024, 11:58am UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/13 "2024-03-03T11:58:03Z")

</div>

> [@ivanpribec](#):
>
> By the looks of it, the SQLite library I installed is missing this particular function.

The function was introduced in SQLite 3.39.0.

> [@ivanpribec](#):
>
> @interkosmos, can you show what you get on your system?

The output is:

```auto
ptr.....: F
stmt....: F
open....: T
prepare.: T
finalize: T
 before close 38143136
 before close 5648439
close...: T

```

The used compiler is `ifx 2024.0.0 20231017`.

Weirdly, the output stays the same when setting `ptr` explicitly to `c_null_ptr`:

```fortran
    print *, 'before close', transfer(ptr, 1_c_intptr_t)
    rc = sqlite3_close(ptr)
    ptr = c_null_ptr
    print *, 'before close', transfer(ptr, 1_c_intptr_t)
    print '("close...: ", L)', c_associated(ptr) 

```

And with _ifort_:

```auto
$ ifort --version
ifort (IFORT) 2021.11.0 20231010
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.
$ ifort -o demo demo.f90 libfortran-sqlite3.a -lsqlite3
$ ./demo
ptr.....: F
stmt....: F
open....: T
prepare.: T
finalize: T
 before close 19629240
 before close 4690047
close...: T

```

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 3, 2024, 12:15pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/14 "2024-03-03T12:15:36Z")

</div>

On the systems I’ve tested, the statement

```auto
print *, transfer(c_null_ptr,1_c_intptr_t)

```

would print 0, matching the POSIX standard behavior of [representing C’s `NULL` as 0](https://man7.org/linux/man-pages/man3/NULL.3const.html). The fact that you don’t see this is proof of a bug IMO.

I suggest reporting it via the Intel Fortran Forum ([Intel® Fortran Compiler - Intel Community](https://community.intel.com/t5/Intel-Fortran-Compiler/bd-p/fortran-compiler)).

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [March 3, 2024, 12:20pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/15 "2024-03-03T12:20:22Z")

</div>

> [@interkosmos](#):
>
> And with _ifort_:
> 
> ```txt
> $ ifort --version
> ifort (IFORT) 2021.11.0 20231010
> Copyright (C) 1985-2023 Intel Corporation. All rights reserved.
> $ ifort -o demo demo.f90 libfortran-sqlite3.a -lsqlite3
> $ ./demo
> ptr.....: F
> stmt....: F
> open....: T
> prepare.: T
> finalize: T
> before close 19629240
> before close 4690047
> close...: T
> 
> ```

Did you also rebuild the library ` libfortran-sqlite3.a` with ifort?

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 3, 2024, 12:34pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/16 "2024-03-03T12:34:12Z")

</div>

> [@ivanpribec](#):
>
> Did you also rebuild the library ` libfortran-sqlite3.a` with ifort?

Yes, with the same outcome.

---

<div class="post-metadata">

**Author:** ![greenrongreen](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/greenrongreen/32/1249_2.png) [@greenrongreen](https://fortran-lang.discourse.group/u/greenrongreen)\
**Post date:** [March 6, 2024, 6:23pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/17 "2024-03-06T18:23:45Z")

</div>

I’ll try this example with an early build of 2024 Update 1 and our main branch and report back. If it’s still present in Update 1 and main branch I’ll get a bug report entered.

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [March 6, 2024, 6:56pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/18 "2024-03-06T18:56:16Z")

</div>

Thank you!

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [April 11, 2024, 9:50pm UTC](https://fortran-lang.discourse.group/t/c-pointer-not-nullified-using-intel-oneapi-fortran/7518/19 "2024-04-11T21:50:49Z")

</div>

The problem remains with Intel oneAPI 2024.1.