http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #12 from Fran Martinez Fadrique <fmartinez at gmv dot com>
2012-11-27 09:49:20 UTC ---
After readign the standard carefully again (I have the formal version for f2k3,
not the draft for f2k8) I cannot really see how the need for the interfaces to
be unique can be derived. Regardless whether some compilers issue certains
messages or not; actually this is also just different interpretations of the
same text.
The propotype for SQLSetEnvAttr I do not think that realy matters for the
discussion but I have added at the end of this comment.
>From what I see, the interface need not be unique (I share the point with Juno)
The bahaviour that I would expect (and this is again just an interpretation) is
that for a definition of a Fortran interface, when invoked, a C function is
called based on the provided label (from the f2k3 'A reference to such a
procedure causes the function described by the C prototype to be called as
...'). Not mandatory to be always a different one; maybe.
15.4.1 Binding labels for procedures defines how a label must be defined and
behaves with respect to the defining fortran interface but it says nothing
about being unique.
In my case I have to invoke SQLSetEnvAttr with more than one represetnation of
the ValuePtr (this is because of the way in which the ODBC library behaves
internally; not very nice) and in the way I see the implementation once I need
the void * to behave as an integer and then as an actual pointer (c_ptr).
I'll try to find another way out of this, but the one I tried seem to be the
natural one.
I'll give c_intptr_t an opprtunity; it is not in my standard and I had not
consider it all (not awware of it actually).
SQLRETURN SQLSetEnvAttr(
SQLHENV EnvironmentHandle,
SQLINTEGER Attribute,
SQLPOINTER ValuePtr,
SQLINTEGER StringLength);
SQLHENV = void *
SQLINT = int
SQLPOINTER = void *
