Nick Maclaren writes:

It would also allow (for example) the C library function isalnum() to be called from Fortran.

Already allowed, not a problem. You just declare it with type INTEGER(C_int) and use isalnum(...)/=0. The problem, such as it exists, arises if you allow LOGICAL instead of INTEGER on the Fortran side. Fortran LOGICAL only has two values, .TRUE. and .FALSE., whereas C's "boolean" use of integers has many values but only 2 equivalence classes (true and false). This is very different: a Fortran compiler might, for example, test the sign bit for logical testing. Or the bottom bit. Or do .AND. with bitwise AND (this latter is quite common in particular circumstances!). All these are perfectly valid for Fortran (I've seen 'em all), but do not interoperate well with C. This means that if you have LOGICAL on the Fortran side, either (a) the C routine always returns the same bitwise value for TRUE, and you got lucky and that bit-value is the one the Fortran compiler uses for LOGICAL, or (b) you need a wrapper that ensures the conditions in (a). Otherwise cue all kinds of incredibly obscure "incorrect results", that only occur in some cases and only with some compilers and/or some compilation options. Ugh. FWIW the NAG compiler currently uses 0 and 1 for LOGICAL, which works nicely with C relationals, and does use bitwise-and for LOGICAL .AND. operations under some circumstances. (On some ancient platforms we used 0 and -1 for compatibility with other Fortran compilers, but those machines aren't around any more.) Cheers, -- .......................Malcolm Cohen on holiday.