BIND(C) functions in a module error
in [Fortran]
|
Prev: unformatted files (again)
Next: Darvon online no prescription. Darvon online prescriptions with no membership. no prescription Darvon fedex delivery
From: Nick Maclaren on 7 Aug 2010 12:42 In article <1jmuj7v.1t5bkid1j32auaN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: >glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > >> Now, why is it that Fortran declarations aren't all sequence type >> declarations? > >I think I'm just going to stop with "because that's the way the votes >came out." Maybe I'll add that I'd have voted the same way (it was well >before my time on the committee, so I didn't actually have the chance), >but I'm not going to try to recite what I recall of the various >arguments for or against. And, if I had been on it, I would have voted against ANY being! I don't know what arguments were used, but I know a fair number that could have been (on both sides). Regards, Nick Maclaren.
From: Richard Maine on 7 Aug 2010 12:44 Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote: > In article <1jmuj7v.1t5bkid1j32auaN%nospam(a)see.signature>, > Richard Maine <nospam(a)see.signature> wrote: > >glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > > >> Now, why is it that Fortran declarations aren't all sequence type > >> declarations? > > > >I think I'm just going to stop with "because that's the way the votes > >came out." Maybe I'll add that I'd have voted the same way (it was well > >before my time on the committee, so I didn't actually have the chance), > >but I'm not going to try to recite what I recall of the various > >arguments for or against. > > And, if I had been on it, I would have voted against ANY being! Well, now that you mention it, that too. :-) -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 7 Aug 2010 14:14 Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote: > In article <i3j22c$bph$1(a)speranza.aioe.org>, > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >>More fundamentally, C requires that different declarations of >>the same struct are equivalent, usually through an #include file >>but they don't have to be done that way. > You will clearly be surprised to know that is NOT so, but you will > probably never encounter a compiler where they aren't. You MIGHT > hit one of the circumstances where you get an error message, though. > So, in practice, you are effectively correct - but not formally! I used to read comp.lang.c, but it takes so long, and I never really learned much from it. I do remember much discussion of the "as if" rule, which isn't actually a rule. There is also the famous case of a compiler that converts between array of struct and struct of array, such that one program runs much faster. That case would seem to violate the struct declaration rules. It would be nice to have an example of the case you are considering. > That is yet another example where the C standard has conflicting > wording, and where merely reading it will not help with deciding > which wording overrides which other wording. Even so, it seems to work most of the time. > On my list is to create some interpretation requests in the area of > C Interopability, where Fortran has made assumptions that go beyond > what C specifies. One that I wondered about long ago, but never looked into more, relates to enum variables and constants. In C, enum constants are int, even if enum variables are smaller. Also, character constants are int, though character variables are usually smaller. With call by value and the usual promotions, this isn't a problem in C. You can't use the & (address of) operator on constants. As far as I know, though, Fortran allows passing either as an actual argument, which would seem to cause problems if not passed by value. -- glen
From: Nick Maclaren on 7 Aug 2010 15:23 In article <i3k7ps$bsl$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > >>>More fundamentally, C requires that different declarations of >>>the same struct are equivalent, usually through an #include file >>>but they don't have to be done that way. > >> You will clearly be surprised to know that is NOT so, but you will >> probably never encounter a compiler where they aren't. You MIGHT >> hit one of the circumstances where you get an error message, though. >> So, in practice, you are effectively correct - but not formally! > >I used to read comp.lang.c, but it takes so long, and I never >really learned much from it. It was a disaster. There were clued-up posters, but the majority didn't have a clue - and, I regret to say, that included a fair number who were on WG14. > I do remember much discussion of >the "as if" rule, which isn't actually a rule. ... Oh, yes, it is. But not in so many words, though I recall it being in the Rationale. See section 4. Conformance and 5.1.2.3 Program execution, paragraphs 1, 5 and 9. >It would be nice to have an example of the case you are considering. Different declarations have different scopes (in general), and there is the classic example of using a struct declaration in a parameter list, which matches no type outside that! And, despite the common belief, there is NO general requirement that all structs with the same sequence of types have the same padding. The only exception to this is when they occur within the same union (see 6.5.2.3 Structure and union members paragraph 5). >> That is yet another example where the C standard has conflicting >> wording, and where merely reading it will not help with deciding >> which wording overrides which other wording. > >Even so, it seems to work most of the time. As I said, it will. But it's not what the standard says - though that bears a decreasingly close relationship to reality as time goes on. C99 got the thumbs down from the IT community, and almost nobody gives a damn about the planned C1X. Whether C++0X will change that, because it has implicitly included much of C99 without actually addressing the problems, God alone knows. >> On my list is to create some interpretation requests in the area of >> C Interopability, where Fortran has made assumptions that go beyond >> what C specifies. > >One that I wondered about long ago, but never looked into more, >relates to enum variables and constants. In C, enum constants >are int, even if enum variables are smaller. Also, character >constants are int, though character variables are usually smaller. > >With call by value and the usual promotions, this isn't a problem >in C. You can't use the & (address of) operator on constants. >As far as I know, though, Fortran allows passing either as an >actual argument, which would seem to cause problems if not >passed by value. It's not a problem. You can't pass constants between the two, not least because they are conceptually incompatible - in any case, you can't pass a constant as a C parameter. All such arguments are variables with the C constant as their value. Regards, Nick Maclaren.
From: M.S. Breitenfeld on 9 Aug 2010 11:09
Sorry, it was an oversight on my part in making up my mini-program to redeclare the type. In the complete program info_t is just used in the function liter_cb and no where else in the Fortran code (link_info is only used in the C code, at least for now). Moving the TYPE declaration to the module scope fixes the compilation errors with gfortran and Portland Group's compiler as well. Thanks for all the input. > > Anyway, if I move the derived type definition out to module scope, where > I would normally put it if I were writing the code, then the whole thing > becomes > > MODULE liter_cb_mod > USE ISO_C_BINDING > TYPE, bind(C) :: info_t > INTEGER(c_int) :: type > END TYPE info_t > > CONTAINS > FUNCTION liter_cb(link_info) bind(C) > USE ISO_C_BINDING > IMPLICIT NONE > > INTEGER(c_int) liter_cb > > > TYPE(info_t) :: link_info > > liter_cb = 0 > > END FUNCTION liter_cb > > END MODULE liter_cb_mod > > PROGRAM main > use liter_cb_mod > > type(info_t) :: link_info > > write (*,*) liter_cb(link_info) > > END PROGRAM main > > which works fine with both Nag and g95 on this machine. > |