..
Any ideas?
On Sunday, April 17, 2022 at 11:42:18 AM UTC-4, Thomas Koenig wrote:
..
Any ideas?
The standard intrinsic module "ISO_C_BINDING" also includes the named constants of c_int32_t and c_int64_t (and also c_int16_t and c_int8_t).
Toward generic interfaces these named constants are to be preferred over c_int, c_long, etc. precisely because of the issue encountered in the original post.
FortranFan <parekhvs@gmail.com> schrieb:
On Sunday, April 17, 2022 at 11:42:18 AM UTC-4, Thomas Koenig wrote:
..
Any ideas?
The standard intrinsic module "ISO_C_BINDING" also includes the named constants of c_int32_t and c_int64_t (and also c_int16_t and c_int8_t).
Toward generic interfaces these named constants are to be preferred over c_int, c_long, etc. precisely because of the issue encountered in the original post.
... which does not help if the binding is specified as "long".
..
... which does not help if the binding is specified as "long".
On Sunday, April 17, 2022 at 11:42:18 AM UTC-4, Thomas Koenig wrote:
..
Any ideas?
The standard intrinsic module "ISO_C_BINDING" also includes the named constants of c_int32_t and c_int64_t (and also c_int16_t and c_int8_t).
Toward generic interfaces these named constants are to be preferred over c_int, c_long, etc. precisely because of the issue encountered in the original post.
On 4/17/22 10:51 AM, Thomas Koenig wrote:
FortranFan <parekhvs@gmail.com> schrieb:
On Sunday, April 17, 2022 at 11:42:18 AM UTC-4, Thomas Koenig wrote:
..
Any ideas?
The standard intrinsic module "ISO_C_BINDING" also includes the named constants of c_int32_t and c_int64_t (and also c_int16_t and c_int8_t).
Toward generic interfaces these named constants are to be preferred over c_int, c_long, etc. precisely because of the issue encountered in the original post.
... which does not help if the binding is specified as "long".
Can you do something like
if ( c_int32_t .eq. c_long ) then
...
elseif ( c_int64_t .eq. c_long ) then
...
else
On Sunday, April 17, 2022 at 11:51:55 AM UTC-4, Thomas Koenig wrote:
..
... which does not help if the binding is specified as "long".
Toward this, it will be useful to know about these existing C functions.
FortranFan schrieb:
On Sunday, April 17, 2022 at 11:51:55 AM UTC-4, Thomas Koenig wrote:
..
... which does not help if the binding is specified as "long".
Toward this, it will be useful to know about these existing C functions.The prototype is (paraphrased)
foo_add (foo_type *, foo_type * const, long);
where foo_add is from an external library I have no control over.
On the Fortran side, I would like to do
type(foo_type) :: a, b
b = a + 1
where addition is meaningful for foo_type, and I would also like
to be able to do have another kind of integer, so this can be used
using operators following normal Fortran rules (as far as possible).
On Sunday, April 17, 2022 at 1:16:23 PM UTC-4, Thomas Koenig wrote:
FortranFan schrieb:
On Sunday, April 17, 2022 at 11:51:55 AM UTC-4, Thomas Koenig wrote:
..
... which does not help if the binding is specified as "long".
Toward this, it will be useful to know about these existing C functions. >> The prototype is (paraphrased)
foo_add (foo_type *, foo_type * const, long);
where foo_add is from an external library I have no control over.
On the Fortran side, I would like to do
type(foo_type) :: a, b
b = a + 1
where addition is meaningful for foo_type, and I would also like
to be able to do have another kind of integer, so this can be used
using operators following normal Fortran rules (as far as possible).
Perhaps you will see my minimal but fully working example upthread: https://groups.google.com/g/comp.lang.fortran/c/JgeUMfTHIuA/m/so1jiycPEgAJ
..
Unfortunately, this does not work for what I had in mind (which I
also explained upthread). The problem I am trying to address is
on the Fortran side, in the interface block, when c_int == c_long.
So, I guess there is no way to do what I need in the Fortran language,
and configure / preprocessor hackery it shall be.
Unfortunately, this does not work for what I had in mind (which I also explained upthread). The problem I am trying to address is on the
Fortran side, in the interface block, when c_int == c_long.
So, I guess there is no way to do what I need in the Fortran language,
and configure / preprocessor hackery it shall be.
On Sun, 17 Apr 2022 17:43:33 -0000 (UTC), Thomas Koenig wrote:
Unfortunately, this does not work for what I had in mind (which I also
explained upthread). The problem I am trying to address is on the
Fortran side, in the interface block, when c_int == c_long.
So, I guess there is no way to do what I need in the Fortran language,
and configure / preprocessor hackery it shall be.
I haven't been following this discussion all that closely, but I think
that FortranFan had the right idea. The compiler doesn't choose a
particular module procedure on the basis of the text strings "c_int" or "c_long". It chooses on the basis of the kind values assigned to those strings. Therefore, if you write module procedures using all combinations
of "c_int32_t" and "c_int64_t", one and only one of those procedures will
be chosen regardless of whether or not c_int == c_long. Doesn't this
solve your problem?
On Sunday, April 17, 2022 at 1:43:36 PM UTC-4, Thomas Koenig wrote:
..
Unfortunately, this does not work for what I had in mind (which I
also explained upthread). The problem I am trying to address is
on the Fortran side, in the interface block, when c_int == c_long.
So, I guess there is no way to do what I need in the Fortran language,
and configure / preprocessor hackery it shall be.
Another thing I would try is c_size_t instead of c_int / c_long
kinds in the Fortran INTERFACE construct and with a single function definition in that construct:
FortranFan schrieb:
..
Another thing I would try is c_size_t instead of c_int / c_long..
This would fail for the code (on the Fortran side) of
a = b + 1
when c_size_t does not match Fortran's standard integer.
..
I have already explained that size_t is not good enough for what I have
in mind.
..
Of course, a user using c_long will be restricted by the semantics
of C's long data type.
On Monday, April 18, 2022 at 4:08:05 AM UTC-4, Thomas Koenig wrote:
FortranFan schrieb:
..
Another thing I would try is c_size_t instead of c_int / c_long..
This would fail for the code (on the Fortran side) of
a = b + 1
when c_size_t does not match Fortran's standard integer.
See the fully worked out example upthread with c_size_t: https://groups.google.com/g/comp.lang.fortran/c/JgeUMfTHIuA/m/GFMazEQUEgAJ
Note again in the Fortran standard, no interoperability is
indicated of a Fortran "standard integer" with C. To state the
obvious, what the standard states is that with a companion C
processor, objects of certain types and kinds are interoperable.
In the case of integer, these of course include kinds such as c_int,
c_long, c_int32_t, c_size_t, etc. provided they are consistent
with the parameters defined in the companion C processor.
Thus an instruction such as "a = b + 1" should not be expected
to be interoperable to begin with.
The `long` data type in C has long been a cause of confusion
with many unsuspecting coders, particularly with the upgrade to
64-bit Linux platforms. Our approach is generally to refactor the
C code such that the use of this data type is suitably replaced
with a clear, "modern" option. > >
I have a C functions I want to interface to, which takes a long
argument. I also want to have a wrapper function in Fortran
around it, and operator overloading for it which works for as many
kinds as possible.
I can then chose a module procedure, but it would silently generate
wrong code if "long" is 32 bits and I am trying to pass a 64-bit
integer from Fortran.
Any ideas?
FortranFan <parekhvs@gmail.com> schrieb:
The `long` data type in C has long been a cause of confusion
with many unsuspecting coders, particularly with the upgrade to
64-bit Linux platforms. Our approach is generally to refactor the
C code such that the use of this data type is suitably replaced
with a clear, "modern" option. > >
Not possible in this case - the type is fixed (and for good reason,
too).
What could actually solve this is some sort of "weak" interface
which says "If I specified the same interface before, please
disregard this one".
On Monday, April 18, 2022 at 9:22:47 AM UTC-7, Thomas Koenig wrote:
(snip)
What could actually solve this is some sort of "weak" interfaceCould be nice for all declarations. If I dimension an array twice,
which says "If I specified the same interface before, please
disregard this one".
to the same dimension, ignore the second one. Most languages
don't do that.
C #include files often include a test and #ifdef to avoid the problem
of declaring the same thing twice.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 157 |
Nodes: | 16 (0 / 16) |
Uptime: | 15:51:59 |
Calls: | 3,193 |
Files: | 10,512 |
Messages: | 2,978,671 |