Is it possible to assign a pointer to a variable?


I was wondering if it is possible to assign a pointer to a variable like in C++ for instance, in order to access the value stored by this variable using (*).

Why would you want to do that? Do you have a specific scenario in mind?

I have a set of functions that I have converted from c++ to FreeFem++ format and some of them have arguments assigned by a unary operator (*). So I am having trouble in passing arguments to these types of functions in FreeFem++ especially functions that have MPI_Comm as argument.

Couldn’t you pass references instead of addresses? Could you post a small code snippet?

This is one of the functions that I defined:

long CwipiInitFfpp(MPI_Comm const &common_comm, string *const &application_name, MPI_Comm *const &application_comm){
cwipi_init( cwipi_init, (const char *) application_name, application_comm);
return 0L;

In FreeFem++ I use It as follows (just to test the arguments):
string test = “test”;
mpiComm Comm(mpiCommWorld, 0, 0);
mpiComm Comm2(mpiCommWorld, 0, 0);
CwipiInitFfpp(Comm, test, Comm2);

What is wrong with this code and/or what would you want to do instead?

The problem is when passing MPI arguments FreeFem++ gives a segmentation fault error, I checked both the cpp file and the edp file and they do have the same compiler, I thought maybe it is because of the pointer type FreeFemm++ doesn’t understand it. Maybe the MPI library used in FreeFem++ is different from the one used in CWIPI? they are both used in C++ though

Could you please give a backtrace of the segmentation fault?

17 : CwipiInitFfpp(Comm, test, Comm2)[0]PETSC ERROR: ------------------------------------------------------------------------

[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range

[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger

[0]PETSC ERROR: or see

[0]PETSC ERROR: or try on GNU/linux and Apple Mac OS X to find memory corruption errors

[0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run

[0]PETSC ERROR: to get more information on the crash.

[0]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------

[0]PETSC ERROR: Signal received

[0]PETSC ERROR: See for trouble shooting.

[0]PETSC ERROR: Petsc Release Version 3.15.0, Mar 30, 2021

[0]PETSC ERROR: /home/cfd/mnoun/freefem/4.9/bin/FreeFem+±mpi on a named krakenv6 by mnoun Mon Nov 22 15:20:51 2021

[0]PETSC ERROR: Configure options --prefix=/home/cfd/mnoun/freefem/4.9/ff-petsc/r MAKEFLAGS= --with-debugging=0 COPTFLAGS="-O3 -mtune=generic" CXXOPTFLAGS="-O3 -mtune=generic" FOPTFLAGS="-O3 -mtune=generic" --with-cxx-dialect=C++11 --with-ssl=0 --with-x=0 --with-fortran-bindings=0 --with-cudac=0 --with-cc=/softs/intel/impi/2018.1.163/bin64/mpicc --with-cxx=/softs/intel/impi/2018.1.163/bin64/mpicxx --with-fc=/softs/intel/impi/2018.1.163/bin64/mpif90 --with-scalar-type=real --with-blaslapack-include= --with-blaslapack-lib="-llapack -lblas" --download-metis --download-ptscotch --download-hypre --download-parmetis --download-mmg --download-parmmg --download-superlu --download-suitesparse --download-tetgen --download-slepc --download-hpddm --download-scalapack --download-mumps --download-slepc-configure-arguments=–download-arpack= PETSC_ARCH=fr

[0]PETSC ERROR: #1 User provided function() at unknown file:0

[0]PETSC ERROR: Run with -malloc_debug to check if memory corruption is causing the crash.

application called MPI_Abort(MPI_COMM_WORLD, 50176059) - process 0

This is the PETSc backtrace, which is not very meaningful here. Need to run with -start_in_debugger and then use GDB to get the backtrace of your plugin.

I think I figured out what the problem is, I am passing an mpiComm argument to my function that takes an MPI_Comm argument. I tried declaring the original function in a function that takes a string as argument only and it worked:

long CwipiInitFfpp(string *const &application_name){
MPI_Comm temp;
MPI_Comm_dup(MPI_COMM_WORLD, &temp);
cwipi_init( MPI_COMM_WORLD, (const char *) application_name, (&temp) );
return 0L;

This bieng said is the mpiComm in FreeFemm++ different from the MPI_Comm in C++ ?

It shouldn’t be different, but FreeFEM pass a reference, and it looks like your function cwipi_init may overwrite it. You can look, for example, at src/mpi/parallelempi.cpp, function mpiCommSplit, to do what you want, I think.