This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: f03 c interop status, etc..


Christopher D. Rickett wrote:
> i am currently able to parse the bind(c) (with optional name= attribute if 
> appropriate) for procedures, derived types, common blocks, and global 
> variables.  this includes the ability to specify the bind(c) attribute as 
> a statement on a separate line from the declaration, though this is not 
> finished because you could see the bind(c) before the declaration of an  
> entity (good example is common blocks from note 15.24 of f03 draft).  
> then, once you see the declaration, you have to verify all elements w/in 
> the block are c interoperable.  the correct binding label, either the given 
> name= C name or the name of the object in all lowercase, is generated into 
> the obj file.  therefore, C is able to call into fortran using the bind(c) 
> rules of f03, fortran can call C using the f03 rules, and global vars, 
> common blocks (mostly), etc. are currently interoperating.  the common 
> blocks are not complete, and error checking is not complete since i have not 
> finished the interoperable types.  so, there's a bit of handwaving by 
> knowing the real in f90 is the same as a c float, etc, on my box.  i'm 
> currently finishing the work on derived types that are bind(c); the syntax 
> is being parsed but the symbol update/generation for the obj isn't complete 
> yet, but should be fairly soon.  

Thanks for the information.

> also, i have a question concerning the use of goto's.  i've seen them used 
> throughout the code that i've looked at, though i don't use them myself.  
> is there a reason for using them to build constructs rather than using the 
> language constructs themselves?

They're used for error recovery and as equivalent of exit in nested loops.
Both cases where language features which are more Dijkstraesque are lacking in
C.  If you think you can clean up the code, feel free to do so, but there's no
reason to not write goto where it makes sense.

- Tobi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]