Implementation of ISO_Fortran_binding.c and .h files

Implementation of ISO_Fortran_binding.c and .h files

[Jerry DeLisle]

Hi all,

Daniel Garza is implementing the subject files.

I have a question.  Should the functions in the .c file become part of 
libgfortran or in a separate library file of their own?

I must admit I have not read through the standard, but I assume that 
anyone using the functions in a C program need to link to something.

Regards,

Jerry

Re: Implementation of ISO_Fortran_binding.c and .h files

[Steve Kargl]

On Sat, Apr 14, 2018 at 01:14:38PM -0700, Jerry DeLisle wrote:
> 
> I have a question.  Should the functions in the .c file become part of 
> libgfortran or in a separate library file of their own?

Good question.  The functions seems to be prefixed by CFI_,
so libgfortran would now have additional namespace pollution.
An effort had been made to prefix functions with _gfortran_
or _gfortrani_.  There appears to be two exceptions.  The
backtrace function start with backtrace_.  libgfortran will
also include fallback C99 functions if a target does not
provide them (e.g., round(), roundf(), and roundl()).
These CFI_ functions however would be inaccessible from a
Fortran program (without a bind c name clause).  So, the
namespace pollution isn't too bad.  I suspect that users 
who want/need the CFI_ functions will be doing mixed 
fortran/C language programming.  Might as well put them in
libgfortran.a

Just my $0.02.

-- 
Steve

Re: Implementation of ISO_Fortran_binding.c and .h files

[Thomas Koenig]

Hi Jerry,

> Daniel Garza is implementing the subject files.
> 
> I have a question.  Should the functions in the .c file become part of 
> libgfortran or in a separate library file of their own?

I think they should be part of libgfortran. It's part of the language,
it needs to use information from ligbgfortran.h, and adding a new
library just adds complexity we do not need.

Regards

	Thomas