Aleksandar Donev asked: > Absoft claims that this interface is ambiguous: > > INTERFACE C_LOC_Function > MODULE PROCEDURE C_LOC_Function_i_sp > MODULE PROCEDURE C_LOC_Function_i_dp > END INTERFACE > > where the aformentioned procedures have interfaces: > > FUNCTION C_LOC_Function_i_sp (X) RESULT (c_pointer) > INTEGER (i_sp), EXTERNAL :: X > INTEGER (KIND=C_ADDRESS) :: c_pointer > END FUNCTION > > FUNCTION C_LOC_Function_i_dp (X) RESULT (c_pointer) > INTEGER (i_dp), EXTERNAL :: X > INTEGER (KIND=C_ADDRESS) :: c_pointer > END FUNCTION > > I recall J3 recently discussed interps related to this. All my other > compilers accept it just fine. > > Is the above interface in fact legal in F95? Presumably there's more to it than this -- definition of kind type parameters in particular. This could well be a portability problem, not a language problem. If, for example, i_sp is selected_int_kind(4) and i_dp is selected_int_kind(8), it may be that i_sp and i_dp have the same value on some processors, and different values on others. This is one of the reasons to want to be able to develop new types from existing ones (actually, I would call them "subtypes" because you'd want the new ones to inherit operations from the original ones). If we could have, for example subtype :: integer_i_sp => integer(i_sp), integer_i_dp => integer(i_dp) then integer_i_sp and integer_i_dp would be different subtypes, even if i_sp and i_dp happen to have the same value on some platforms. The function declarations could be something like FUNCTION C_LOC_Function_i_sp (X) RESULT (c_pointer) type(INTEGER_i_sp), EXTERNAL :: X INTEGER (KIND=C_ADDRESS) :: c_pointer END FUNCTION and mutatis mutandis for C_LOC_Function_i_dp That the subtypes are different could be exploited for generic resolution. -- Van Snyder | What fraction of Americans believe [log in to unmask] | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.