Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #8703 > unrolled thread
| Started by | Uno <Uno@example.invalid> |
|---|---|
| First post | 2011-07-25 17:45 -0600 |
| Last post | 2011-08-01 15:42 +0100 |
| Articles | 5 on this page of 125 — 33 participants |
Back to article view | Back to comp.lang.c
is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-25 17:45 -0600
Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-25 23:53 +0000
Re: is there anything unstandard in the c part here gwowen <gwowen@gmail.com> - 2011-07-26 01:50 -0700
Re: is there anything unstandard in the c part here tom st denis <tom@iahu.ca> - 2011-07-26 06:17 -0700
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 11:08 -0400
Re: is there anything unstandard in the c part here tom st denis <tom@iahu.ca> - 2011-07-26 10:51 -0700
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:08 -0700
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-27 13:41 -0400
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 10:58 +0000
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 13:58 +0100
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-27 13:24 -0400
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 11:07 +0000
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-28 13:02 -0400
Re: is there anything unstandard in the c part here Roberto Waltman <usenet@rwaltman.com> - 2011-07-28 17:16 -0400
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-26 09:39 -0400
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-07-27 07:24 +0100
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 07:11 -0400
Re: is there anything unstandard in the c part here Noob <root@127.0.0.1> - 2011-07-27 15:20 +0200
Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-27 14:25 +0000
Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-07-27 08:10 -0700
Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-27 17:42 +0000
Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-07-27 12:02 -0700
Re: is there anything unstandard in the c part here Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-28 16:04 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 22:35 -0400
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-27 13:34 -0400
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 02:13 +0100
Re: is there anything unstandard in the c part here Ike Naar <ike@sverige.freeshell.org> - 2011-07-28 07:33 +0000
Re: is there anything unstandard in the c part here Willem <willem@toad.stack.nl> - 2011-07-28 07:58 +0000
Re: is there anything unstandard in the c part here pete <pfiland@mindspring.com> - 2011-07-28 04:25 -0400
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 12:26 +0100
Re: is there anything unstandard in the c part here gwowen <gwowen@gmail.com> - 2011-07-28 04:24 -0700
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 11:36 +0000
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 15:11 +0100
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-28 14:50 +0000
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 17:28 +0100
Re: is there anything unstandard in the c part here Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-28 10:38 -0600
Re: is there anything unstandard in the c part here Michael Press <rubrum@pacbell.net> - 2011-08-02 17:20 -0700
Re: is there anything unstandard in the c part here Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-08-02 23:26 -0600
Re: is there anything unstandard in the c part here Michael Press <rubrum@pacbell.net> - 2011-08-03 16:09 -0700
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-28 13:22 -0400
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-28 22:22 -0400
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-29 04:17 +0100
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-28 23:40 -0400
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-29 13:52 +0100
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-07-31 09:19 +0100
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-31 09:49 -0400
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-02 06:56 +0100
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-02 06:53 -0400
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-28 07:36 -0400
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-28 13:16 -0400
Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-26 14:58 +0000
Re: is there anything unstandard in the c part here Paul N <gw7rib@aol.com> - 2011-07-26 14:56 -0700
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:13 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 07:28 -0400
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 04:44 -0700
Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-07-27 08:24 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-27 22:41 -0400
Re: is there anything unstandard in the c part here Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-28 16:19 -0700
Re: is there anything unstandard in the c part here Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-28 16:06 -0700
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-30 01:54 -0600
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 11:01 -0400
Re: is there anything unstandard in the c part here Chad <cdalten@gmail.com> - 2011-07-26 09:49 -0700
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 13:18 -0400
Re: is there anything unstandard in the c part here John Gordon <gordon@panix.com> - 2011-07-26 17:44 +0000
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-26 17:45 +0000
Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 18:42 +0000
Re: is there anything unstandard in the c part here Bill Waddington <william.waddington@beezmo.com> - 2011-07-26 11:55 -0700
Re: is there anything unstandard in the c part here lawrence.jones@siemens.com - 2011-07-26 18:11 -0400
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-27 20:58 -0600
Re: is there anything unstandard in the c part here arnuld <sunrise@invalid.address> - 2011-08-02 05:24 +0000
Re: is there anything unstandard in the c part here Ian Collins <ian-news@hotmail.com> - 2011-08-02 18:10 +1200
Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-08-02 00:03 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-02 06:59 -0400
Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-08-02 16:06 +0000
Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 18:42 +0000
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:06 -0700
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-02 06:58 +0100
Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-08-02 00:01 -0700
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-05 06:22 +0100
Re: is there anything unstandard in the c part here Keith Thompson <kst-u@mib.org> - 2011-08-04 23:54 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-05 07:37 -0400
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-13 08:05 +0100
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-13 08:26 -0400
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-13 14:09 +0100
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-08-02 12:58 -0400
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-10 01:31 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-10 08:28 -0400
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-13 08:14 +0100
Re: is there anything unstandard in the c part here "io_x" <a@b.c.invalid> - 2011-08-13 10:08 +0200
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-08-13 08:35 -0400
Re: is there anything unstandard in the c part here "J. J. Farrell" <jjf@bcs.org.uk> - 2011-08-14 04:00 +0100
Re: is there anything unstandard in the c part here Kenneth Brody <kenbrody@spamcop.net> - 2011-08-15 14:43 -0400
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-10 01:34 -0700
Re: is there anything unstandard in the c part here Gareth Owen <gwowen@gmail.com> - 2011-08-13 08:16 +0100
Re: is there anything unstandard in the c part here Barry Schwarz <schwarzb@dqel.com> - 2011-07-25 17:52 -0700
Re: is there anything unstandard in the c part here "J. J. Farrell" <jjf@bcs.org.uk> - 2011-07-26 02:10 +0100
Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 06:17 +0000
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 00:03 -0700
Re: is there anything unstandard in the c part here "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-26 00:08 -0700
Re: is there anything unstandard in the c part here Ian Collins <ian-news@hotmail.com> - 2011-07-26 19:43 +1200
Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 07:56 +0000
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 04:50 -0700
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-26 12:03 +0000
Re: is there anything unstandard in the c part here Seebs <usenet-nospam@seebs.net> - 2011-07-26 18:42 +0000
Re: is there anything unstandard in the c part here Nobody <nobody@nowhere.com> - 2011-07-27 19:10 +0100
Re: is there anything unstandard in the c part here Angel <angel+news@spamcop.net> - 2011-07-26 11:53 +0000
Re: is there anything unstandard in the c part here Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 00:07 -0700
Re: is there anything unstandard in the c part here James Kuyper <jameskuyper@verizon.net> - 2011-07-26 06:29 -0400
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-27 21:32 -0600
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-28 12:19 +0100
Re: is there anything unstandard in the c part here pete <pfiland@mindspring.com> - 2011-07-28 20:25 -0400
Re: is there anything unstandard in the c part here Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-07-28 18:38 -0600
Re: is there anything unstandard in the c part here pete <pfiland@mindspring.com> - 2011-07-28 21:05 -0400
Re: is there anything unstandard in the c part here "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-07-29 14:16 -0400
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-29 20:27 +0100
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-30 01:10 -0600
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-07-30 00:56 -0600
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-30 12:23 +0100
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-08-01 00:01 -0600
Re: is there anything unstandard in the c part here Ike Naar <ike@sverige.freeshell.org> - 2011-08-01 07:50 +0000
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-08-01 07:43 -0600
Re: is there anything unstandard in the c part here Ike Naar <ike@sdf.lonestar.org> - 2011-08-01 15:20 +0000
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-01 14:27 +0100
Re: is there anything unstandard in the c part here Uno <Uno@example.invalid> - 2011-08-01 08:02 -0600
Re: is there anything unstandard in the c part here Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-01 15:42 +0100
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | Uno <Uno@example.invalid> |
|---|---|
| Date | 2011-08-01 07:43 -0600 |
| Message-ID | <99nor8F2s8U1@mid.individual.net> |
| In reply to | #8919 |
On 08/01/2011 01:50 AM, Ike Naar wrote:
> On 2011-08-01, Uno<Uno@example.invalid> 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
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2011-08-01 15:20 +0000 |
| Message-ID | <slrn3vfsj3dh2a.6va.ike@sdf.lonestar.org> |
| In reply to | #8924 |
On 2011-08-01, Uno <Uno@example.invalid> 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 ?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-08-01 14:27 +0100 |
| Message-ID | <0.adb768f9baf2164e9020.20110801142702BST.87fwllw9cp.fsf@bsb.me.uk> |
| In reply to | #8915 |
Uno <Uno@example.invalid> 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.
[toc] | [prev] | [next] | [standalone]
| From | Uno <Uno@example.invalid> |
|---|---|
| Date | 2011-08-01 08:02 -0600 |
| Message-ID | <99npvaFcenU1@mid.individual.net> |
| In reply to | #8922 |
On 08/01/2011 07:27 AM, Ben Bacarisse wrote:
> Uno<Uno@example.invalid> 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
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-08-01 15:42 +0100 |
| Message-ID | <0.89e20cfcc2a884385216.20110801154212BST.87y5zduraz.fsf@bsb.me.uk> |
| In reply to | #8925 |
Uno <Uno@example.invalid> writes: > On 08/01/2011 07:27 AM, Ben Bacarisse wrote: >> Uno<Uno@example.invalid> 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.
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c
csiph-web