«

On 07/30/2011 05:23 AM, Ben Bacarisse wrote:

> It's almost always the calling function that determines how you must
> interface with the called language. This applies to best practice as
> much as it does to those things that are required.
>

Ok. Fortran is expecting a c-style pointer to a char. This little
snippet gives you a feel for it. This is pretty-new syntax, and what
makes it relevant to c is that fortran said *all* interop is with ISO C.

type(c_ptr):: pa
end function testc
end interface
type(c_ptr), target :: pa
character(1, c_char),pointer::fpa(
pa = testc()

....

Yes the horror of not seeing semicolons, but again I put the fortran
stuff at the top, so it can disappear with a reasonable edit.

On the C side, I think I've got something that works well, but I don't
know that without some code review. This is what dinkumware has for
strncpy; does anyone have a mnemonic for what the 'n' might mean?

strncpy

char *strncpy(char *restrict s1, const char *restrict s2, size_t n);

The function copies the string s2, not including its terminating null
character, to successive elements of the array of char whose first
element has the address s1. It copies no more than n characters from s2.
The function then stores zero or more null characters in the next
elements to be altered in s1 until it stores a total of n characters. It
returns s1.

So I want a char * before i get to this statement, and that leaves the
malloc:

char *p = malloc(sz);

The reason that I might put it on the left is that I haven't been handed
anything that's broken, and if it doesn't draw warnings, then C might be
just fine this.

Another version might be:

char *p = (char *)malloc(sz);
, and I'm naive enough not to see anything wrong there, technically.
But as I'm sitting here, it looks like an unnecessary cast.

$ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
$ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
this sentence is less than fifty bytes.
$ cat caller2.f03
program test
use iso_c_binding
implicit none
interface
function testc() bind(c) result(pa)
use iso_c_binding
type(c_ptr):: pa
end function testc
end interface
type(c_ptr), target :: pa
character(1, c_char),pointer::fpa(
pa = testc()
call c_f_pointer(pa, fpa, [50])
print*, fpa(1:50)
end program test
! gfortran -c -Wall -Wextra caller2.f03 -o caller.o
! gfortran -Wall -Wextra caller.o testc.o -o out

$ indent -i3 cfunc6.c

$ cat cfunc6.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
char *
malloc_or_bust (size_t sz)
{
char *p = malloc (sz);
if (p == NULL)
{
fprintf (stderr, "malloc failed.\n");
exit (EXIT_FAILURE);
}
return p;
}
char *
testc (void)
{
size_t size = 50;
char *p = malloc_or_bust (size);
strncpy (p, "this sentence is less than fifty bytes", size - 1);
p[size - 1] = '\0
return p;
}
// gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
$

Thanks for your comment. How long have I known you now? I bet that
neither of us would move back to Michigan now. what's going on in
upper-midwest states is shocking. The KKK and arsonists have showed up
in 'Sconi ten days before people were almost going to have a free and
fair election.

--
Uno

On 2011-08-01, Uno <> wrote:
> $ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
> $ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
> $ gfortran -Wall -Wextra caller.o testc.o -o out

What is testc.o ?
Is it related to cfunc6.c ?

> $ ./out
> this sentence is less than fifty bytes.

Just curious: where are the leading spaces and the trailing dot from?

> [snip fortran code]

> $ cat cfunc6.c
> #include <stdio.h>
> #include <limits.h>
> #include <stdlib.h>
> #include <string.h>
> char *
> malloc_or_bust (size_t sz)
> {
> char *p = malloc (sz);
> if (p == NULL)
> {
> fprintf (stderr, "malloc failed.\n");
> exit (EXIT_FAILURE);
> }
> return p;
> }
> char *
> testc (void)
> {
> size_t size = 50;
> char *p = malloc_or_bust (size);
> strncpy (p, "this sentence is less than fifty bytes", size - 1);
> p[size - 1] = '\0
> return p;
> }
> // gcc -c -Wall -Wextra cfunc6.c -o cfunc.o

$ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
cfunc6.c: In function 'testc':
cfunc6.c:22: error: missing terminating ' character
cfunc6.c:23: error: expected expression before 'return'
cfunc6.c:24: warning: control reaches end of non-void function

Uno <> writes:

> On 07/30/2011 05:23 AM, Ben Bacarisse wrote:
>
>> It's almost always the calling function that determines how you must
>> interface with the called language. This applies to best practice as
>> much as it does to those things that are required.

I made a mistake. I meant to say "the calling language" not "the
calling function". The point being you need to ask Fortran people about
the best practice.

> Ok. Fortran is expecting a c-style pointer to a char. This little
> snippet gives you a feel for it. This is pretty-new syntax, and what
> makes it relevant to c is that fortran said *all* interop is with ISO
> C.

The C has been discussed and you've decided not to use ISO C for some
reason so what more is there to say here? To get an answer to your
question about best practice you need to ask Fortran people, not C
people. Make sure you tell them what you are trying to do because the
Fortran code you have looks wrong to me.

> type(c_ptr):: pa
> end function testc
> end interface
> type(c_ptr), target :: pa
> character(1, c_char),pointer::fpa(
> pa = testc()
>
> ...
>
> Yes the horror of not seeing semicolons, but again I put the fortran
> stuff at the top, so it can disappear with a reasonable edit.
>
> On the C side, I think I've got something that works well, but I don't
> know that without some code review. This is what dinkumware has for
> strncpy; does anyone have a mnemonic for what the 'n' might mean?

What do you mean "might mean"? You know what it means because you quote
the documentation:

> strncpy
>
> char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
>
> The function copies the string s2, not including its terminating null
> character, to successive elements of the array of char whose first
> element has the address s1. It copies no more than n characters from
> s2. The function then stores zero or more null characters in the next
> elements to be altered in s1 until it stores a total of n
> characters. It returns s1.
>
> So I want a char * before i get to this statement, and that leaves the
> malloc:
>
> char *p = malloc(sz);

There are other ways to get a char *. You can use static storage or you
can have the pointer to some storage passed in. You could even be
passed a pointer to a pointer that you assign from the C function.
Which is considered best practice is something that the Fortran people
can advice you about.

> The reason that I might put it on the left is that I haven't been
> handed anything that's broken, and if it doesn't draw warnings, then C
> might be just fine this.
>
> Another version might be:
>
> char *p = (char *)malloc(sz);
> , and I'm naive enough not to see anything wrong there,
> technically. But as I'm sitting here, it looks like an unnecessary
> cast.

Yes, it's unnecessary.

> $ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
> $ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
> $ gfortran -Wall -Wextra caller.o testc.o -o out
> $ ./out
> this sentence is less than fifty bytes.

This can't be the output of the program you show below. For one thing,
the C has a syntax error and for another there's an extra '.' here.
You've told me that despite appearances, the commands you show do
actually use cfunc.o but I am beginning to doubt that. Where does the
'.' come from.

When the C syntax error is fixed you still don't get what I think you
want:

$ /out | cat -A
this sentence is less than fifty bytes^@^@^@^@^@^@^@^@^@^@^@^@$

The Fortran people can help you fix that (unless you do want this
odd behaviour).

<snip>
> char *
> testc (void)
> {
> size_t size = 50;
> char *p = malloc_or_bust (size);
> strncpy (p, "this sentence is less than fifty bytes", size - 1);
> p[size - 1] = '\0

'; is missing here.

> return p;
> }

<snip>
--
Ben.

On 08/01/2011 01:50 AM, Ike Naar wrote:
> On 2011-08-01, Uno<> wrote:
>> $ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
>> $ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
>> $ gfortran -Wall -Wextra caller.o testc.o -o out
>
> What is testc.o ?
> Is it related to cfunc6.c ?
>
>> $ ./out
>> this sentence is less than fifty bytes.
>
> Just curious: where are the leading spaces and the trailing dot from?
>
>> [snip fortran code]
>
>> $ cat cfunc6.c
>> #include<stdio.h>
>> #include<limits.h>
>> #include<stdlib.h>
>> #include<string.h>
>> char *
>> malloc_or_bust (size_t sz)
>> {
>> char *p = malloc (sz);
>> if (p == NULL)
>> {
>> fprintf (stderr, "malloc failed.\n");
>> exit (EXIT_FAILURE);
>> }
>> return p;
>> }
>> char *
>> testc (void)
>> {
>> size_t size = 50;
>> char *p = malloc_or_bust (size);
>> strncpy (p, "this sentence is less than fifty bytes", size - 1);
>> p[size - 1] = '\0
>> return p;
>> }
>> // gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
>
> $ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
> cfunc6.c: In function 'testc':
> cfunc6.c:22: error: missing terminating ' character
> cfunc6.c:23: error: expected expression before 'return'
> cfunc6.c:24: warning: control reaches end of non-void function

I don't know know how that one got away from me.

$ gcc -c -Wall -Wextra cfunc7.c -o cfunc.o
$ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
$ gfortran -Wall -Wextra caller.o testc.o -o out
$ ./out
this sentence is less than fifty bytes.
$ cat caller2.f03
program test
use iso_c_binding
implicit none
interface
function testc() bind(c) result(pa)
use iso_c_binding
type(c_ptr):: pa
end function testc
end interface
type(c_ptr), target :: pa
character(1, c_char),pointer::fpa(
pa = testc()
call c_f_pointer(pa, fpa, [50])
print*, fpa(1:50)
end program test
! gfortran -c -Wall -Wextra caller2.f03 -o caller.o
! gfortran -Wall -Wextra caller.o testc.o -o out
$ cat cfunc7.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
char *
malloc_or_bust (size_t sz)
{
char *p = malloc (sz);
if (p == NULL)
{
fprintf (stderr, "malloc failed.\n");
exit (EXIT_FAILURE);
}
return p;
}
char *
testc (void)
{
size_t size = 50;
char *p = malloc_or_bust (size);
strncpy (p, "this sentence is less than fifty bytes", size - 1);
p[size - 1] = '\0';
return p;
}
// gcc -c -Wall -Wextra cfunc7.c -o cfunc.o
$

--
Uno

On 08/01/2011 07:27 AM, Ben Bacarisse wrote:
> Uno<> writes:
>
>> On 07/30/2011 05:23 AM, Ben Bacarisse wrote:
>>
>>> It's almost always the calling function that determines how you must
>>> interface with the called language. This applies to best practice as
>>> much as it does to those things that are required.
>
> I made a mistake. I meant to say "the calling language" not "the
> calling function". The point being you need to ask Fortran people about
> the best practice.

They either don't know or don't want to share.
>
>> Ok. Fortran is expecting a c-style pointer to a char. This little
>> snippet gives you a feel for it. This is pretty-new syntax, and what
>> makes it relevant to c is that fortran said *all* interop is with ISO
>> C.
>
> The C has been discussed and you've decided not to use ISO C for some
> reason so what more is there to say here? To get an answer to your
> question about best practice you need to ask Fortran people, not C
> people. Make sure you tell them what you are trying to do because the
> Fortran code you have looks wrong to me.

How do you figure that I'm not using iso C? Is this a criticism of the
fortran part, the C part, or the lack of critical distinction between
the two?
>
>> type(c_ptr):: pa
>> end function testc
>> end interface
>> type(c_ptr), target :: pa
>> character(1, c_char),pointer::fpa(
>> pa = testc()
>>
>> ...
>>
>> Yes the horror of not seeing semicolons, but again I put the fortran
>> stuff at the top, so it can disappear with a reasonable edit.
>>
>> On the C side, I think I've got something that works well, but I don't
>> know that without some code review. This is what dinkumware has for
>> strncpy; does anyone have a mnemonic for what the 'n' might mean?
>
> What do you mean "might mean"? You know what it means because you quote
> the documentation:

N: null, not null, not null newline....
>
>> strncpy
>>
>> char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
>>
>> The function copies the string s2, not including its terminating null
>> character, to successive elements of the array of char whose first
>> element has the address s1. It copies no more than n characters from
>> s2. The function then stores zero or more null characters in the next
>> elements to be altered in s1 until it stores a total of n
>> characters. It returns s1.
>>
>> So I want a char * before i get to this statement, and that leaves the
>> malloc:
>>
>> char *p = malloc(sz);
>
> There are other ways to get a char *. You can use static storage or you
> can have the pointer to some storage passed in. You could even be
> passed a pointer to a pointer that you assign from the C function.
> Which is considered best practice is something that the Fortran people
> can advice you about.
>
>> The reason that I might put it on the left is that I haven't been
>> handed anything that's broken, and if it doesn't draw warnings, then C
>> might be just fine this.
>>
>> Another version might be:
>>
>> char *p = (char *)malloc(sz);
>> , and I'm naive enough not to see anything wrong there,
>> technically. But as I'm sitting here, it looks like an unnecessary
>> cast.
>
> Yes, it's unnecessary.

Ok.
>
>> $ gcc -c -Wall -Wextra cfunc6.c -o cfunc.o
>> $ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
>> $ gfortran -Wall -Wextra caller.o testc.o -o out
>> $ ./out
>> this sentence is less than fifty bytes.
>
> This can't be the output of the program you show below. For one thing,
> the C has a syntax error and for another there's an extra '.' here.
> You've told me that despite appearances, the commands you show do
> actually use cfunc.o but I am beginning to doubt that. Where does the
> '.' come from.
>
> When the C syntax error is fixed you still don't get what I think you
> want:
>
> $ /out | cat -A
> this sentence is less than fifty bytes^@^@^@^@^@^@^@^@^@^@^@^@$
>
> The Fortran people can help you fix that (unless you do want this
> odd behaviour).
>
> <snip>
>> char *
>> testc (void)
>> {
>> size_t size = 50;
>> char *p = malloc_or_bust (size);
>> strncpy (p, "this sentence is less than fifty bytes", size - 1);
>> p[size - 1] = '\0
>
> '; is missing here.
>
>> return p;
>> }
>


I don't know how I missed on all of that.

$ gcc -c -Wall -Wextra cfunc7.c -o cfunc.o
$ gfortran -c -Wall -Wextra caller3.f03 -o caller.o
$ gfortran -Wall -Wextra caller.o cfunc.o -o out
$ ./out
this sentence is less than fifty bytes
$ cat caller3.f03
program test
use iso_c_binding
implicit none
interface
function testc() bind(c) result(pa)
use iso_c_binding
type(c_ptr):: pa
end function testc
end interface
type(c_ptr), target :: pa
character(1, c_char),pointer::fpa(
pa = testc()
call c_f_pointer(pa, fpa, [50])
print*, fpa(1:50)
end program test
! gfortran -c -Wall -Wextra caller3.f03 -o caller.o
! gfortran -Wall -Wextra caller.o cfunc.o -o out
$ cat cfunc7.c
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#include <string.h>
char *
malloc_or_bust (size_t sz)
{
char *p = malloc (sz);
if (p == NULL)
{
fprintf (stderr, "malloc failed.\n");
exit (EXIT_FAILURE);
}
return p;
}
char *
testc (void)
{
size_t size = 50;
char *p = malloc_or_bust (size);
strncpy (p, "this sentence is less than fifty bytes", size - 1);
p[size - 1] = '\0';
return p;
}
// gcc -c -Wall -Wextra cfunc7.c -o cfunc.o
$

It might throw C people off to see the initial space of list-directed
fortran output, like it did me. Without a format specifier, fortran
generates the space for historic reasons.
--
Uno

Uno <> writes:

> On 08/01/2011 07:27 AM, Ben Bacarisse wrote:
>> Uno<> writes:
>>
>>> On 07/30/2011 05:23 AM, Ben Bacarisse wrote:
>>>
>>>> It's almost always the calling function that determines how you must
>>>> interface with the called language. This applies to best practice as
>>>> much as it does to those things that are required.
>>
>> I made a mistake. I meant to say "the calling language" not "the
>> calling function". The point being you need to ask Fortran people about
>> the best practice.
>
> They either don't know or don't want to share.

Odd. I saw lots of helpful answers to your questions there. What I did
not see was the question you asked here that I suggested you ask there.
The only unanswered post I saw was when you posted about C over there;
and that post did not include a question so it's hard to see how it
could have been answered even if it had been taken to be on-topic.

>>> Ok. Fortran is expecting a c-style pointer to a char. This little
>>> snippet gives you a feel for it. This is pretty-new syntax, and what
>>> makes it relevant to c is that fortran said *all* interop is with ISO
>>> C.
>>
>> The C has been discussed and you've decided not to use ISO C for some
>> reason so what more is there to say here? To get an answer to your
>> question about best practice you need to ask Fortran people, not C
>> people. Make sure you tell them what you are trying to do because the
>> Fortran code you have looks wrong to me.
>
> How do you figure that I'm not using iso C?

Your compile lines don't ask for ISO C. You are therefore getting gnu C
which is something not entirely unlike ISO C but is not ISO C. I doubt
it matters since the code you wrote is ISO C, but you are then assuming
that you won't make any changes that will take you away from ISO C and
that compiling as gnu C does not do anything that messes up the Fortran
to C calling.

> Is this a criticism of
> the fortran part, the C part, or the lack of critical distinction
> between the two?
>>
>>> type(c_ptr):: pa
>>> end function testc
>>> end interface
>>> type(c_ptr), target :: pa
>>> character(1, c_char),pointer::fpa(
>>> pa = testc()
>>>
>>> ...
>>>
>>> Yes the horror of not seeing semicolons, but again I put the fortran
>>> stuff at the top, so it can disappear with a reasonable edit.
>>>
>>> On the C side, I think I've got something that works well, but I don't
>>> know that without some code review. This is what dinkumware has for
>>> strncpy; does anyone have a mnemonic for what the 'n' might mean?
>>
>> What do you mean "might mean"? You know what it means because you quote
>> the documentation:
>
> N: null, not null, not null newline....

I would not bother with a mnemonic. Any mnemonic is likely to lead you
astray since the 'n' in strncpy is very subtly different from the 'n'
in, say, strncat. Just get into the habit of having the documentation
handy (it's just a keystroke away in my editor).

<snip>
> It might throw C people off to see the initial space of list-directed
> fortran output, like it did me. Without a format specifier, fortran
> generates the space for historic reasons.

I happen to know some Fortran so that did not bother me. I asked about
the trailing '.' in your sample output. That is very much more
suspicious.

--
Ben.

On 2011-08-01, Uno <> wrote:
> $ gcc -c -Wall -Wextra cfunc7.c -o cfunc.o
> $ gfortran -c -Wall -Wextra caller2.f03 -o caller.o
> $ gfortran -Wall -Wextra caller.o testc.o -o out
> $ ./out
> this sentence is less than fifty bytes.

It looks like you are not running the code generated from cfunc7.c .
What is testc.o ?