Should C_LOC() be PURE?

[joseph-krahn]

I have experimenting with ISO_C_BINDING. There are some cases where a pure routine is useful, but something as trivial as C_LOC() is not pure in Intel Fortan. From the F2003 draft, 13.1: "All standard intrinsic functions are pure." Since F2003 is a stadard intrinsic module, are those functions included? This detail seems to be left out, at least for the draft version.

It seems that C_F_POINTER should also be pure, but F2003 says that the only pure subroutines are MVBITS and MOVE_ALLOC.

[Steven_L_Intel1]

The "standard intrinsic procedures" are those listed in section 13.7 of F2003. Procedures in intrinsic modules are not included. I happen to be writing this from a meeting of the Fortran standards committee (J3) and posed this question - the response from one member was "because we forgot to issue the Ivory Soap certificates". None of the procedures in ISO_C_BINDING are pure, though some might have reasonable right to be. Many of the functions in the IEEE environment modules are elemental, which implies pure. The ISO_C_BINDING functions are not labeled as pure in the draft of Fortran 2008, either.

Is this really something useful?

[joseph-krahn]

MADsblionel:

Is this really something useful?

It is useful to have a pure C_LOC() in order to call pure C routines, which often require passing arguments via C_LOC(). If C is used for computation, and not just miscellaneous syste, calls, then it can be useful. It can be as useful as PURE anywhere else. Besides that, it seems that any intrinsic that meets the requirements for being PURE should always be declared as such.

I was trying to write a utility function to return a plain Fortran string given a C char pointer. This requires the string length specification to be defined by a pure strlen() function. If you try to write such a function in Fortran, it requires C_F_POINTER(), which is also not pure. The work-around is just to use the C strlen() function via an interface where it is declared pure. That's not an example for C_LOC(), but it demonstrates how pure functions can be useful in C interfacing.

There's probably work-arounds in most cases, but why not make things easier?

[jimdempseyatthecove]

Steve,

Since you are at the Fortran standards committee (J3) why not take the opportunity to float a lead balloon. Who knows, it may just float.

The concept to promote (please take liberties in re-expressing in committee-speak) is to have a class of standard functions and subroutines, such as C_LOC(x), who's pure-ness is implementation specific _until_ the committee gets around to declaring it must be implemented as pure. The converse is not true (committee cannotdictate function/subroutine must be non-pure).

Jim Dempsey

[Steven_L_Intel1]

Sorry, it's too late in the process to propose something like that. Also, I can't think of a good justification for it.

[joseph-krahn]

For now, would implementing C_LOC() as pure be non-standard, assuming that F2008 still doesn't define whether or not it should be?

J3 does sometimes write documents to clarify missing or ambiguous information. Maybe it is possible just to put out somehting like this, after F2008 ios finalized. It could be stated that procedures which were not explicitly defined either way, but fit all the rules for being pure should be implemented as pure, and include a list of procedures that it applies to.

I think it would be better to have a lot more TR's, which could work as "test periods", before incorporating the final version into the full standard. That would make it much easier to work out problems using actual practice, instead of spending a lot of effort on theoretical implementations. I think it would be good to organize things similar to OpenGL extensions. A vendor can make an extension via an intrinsic module, named with a common vendor prefix. Official extensions would have a specific prefix, and would be defined via a TR, for features that are intended to become standard.

[Steven_L_Intel1]

I think that, yes, an implementation making C_LOC pure would be a nonconforming implementation. You could submit a request for interpretation, but what you're really asking for is a change in a feature, not a clarification. You still haven't made a case here as to what the benefit of such a change would be. One thing that worries me a bit about this suggestion is that it would then allow C_LOC to appear in a specification expression.

Assuming you are asking for this so that you could use C_LOC in a FORALL, could you not just precompute the locations and store them into an array?

C_LOC has been in the standard for four years now and is widely implemented. Your point about test driving features is good and is often made. Fortran 2003 is full of features that had not been seen before in Fortran compilers, such as parameterized derived types, that proved to be trouble when vendors started to implement them. There is currently heated discussion about the coarrays feature of F2008 and whether part of the functionality should be split into a TR.

[jimdempseyatthecove]

Steve,

>>Assuming you are asking for this so that you could use C_LOC in a FORALL, could you not just pre-compute the locations and store them into an array?

The "problem" is you will have to pre-compute the locations as oppose to directly using C_LOC in a compiler where C_LOC is pure and where the compiler knows it is pure.

If any compiler does not have the extension of the non-sanctioned pure functions as a pure functions then code written with C_LOC required to be pure will fail to compile on those compilers but will compile on the others. With appropriate warning messages (and option to override), the programmer can choose to direct the compiler to to enable/disable the feature. Actually it may not be a compiler switch at all rather it could be which MODULE is used during compilation to specify the interfaces (to intrinsic functions).

Does the F2003 spec require that the compiler ABORT compilation under such circumstances or merely issue a warning?

Jim Dempsey

[Steven_L_Intel1]

Jim, I don't understand your reply. There are only a few places where it matters that a routine is PURE. One is if you call it from a FORALL body, another is if you call it from another PURE routine and a third is if you use it in a specification expression. How would you be using C_LOC in these contexts? My suggestion was to use C_LOC to fill an array (of type C_PTR) with the addresses you need before doing the FORALL or calling the pure routine.

The standard is clear about the contexts that require that a routine you call be PURE (see above). If you use a routine in these contexts that is not pure you'll get an error. The standard does not say what happens if you violate this rule.

I still have not seen an explanation as to why you'd care whether C_LOC was pure or not. What type of programming construct would run into this and why aren't the alternatives acceptable?

[joseph-krahn]

MADsblionel:

... My suggestion was to use C_LOC to fill an array (of type C_PTR) with the addresses you need before doing the FORALL or calling the pure routine.

That is a work-around for one case, but it would be cumbersome becuase a C-implemented math function could not directly be used in an expression. The ability to write elemental functions usable in expressions is one reason why PURE was created.

My point is that the functionality of C_LOC() really is pure, so why not just declare it as pure, and avoid the work-around hassles? I started this thread just because I was surprised that the seemingly-pure functions were implemented as non-PURE. However, if this constitutes an actual change in the standard and not just a clarification, I agree that this is not a valid justification.

MADsblionel:

I still have not seen an explanation as to why you'd care whether C_LOC was pure or not. What type of programming construct would run into this and why aren't the alternatives acceptable?

I came across this trying to work with C strings via C library functions. I don't remember the context of C_LOC(), but I do have an example for C_ASSOCIATED(). I want to create automatic strings or function results where the string length is defined by the C-string pointer argument. The reason I need C_ASSOCIATED() for the pure string-length function is that I want to support NULL as a zero-length string.

In most cases, temporaries can just be regular allocatables, where PURE is not needed. This would not be an issue if length was a parameter defined with ALLOCATE(), which I think is included in F2008. So, if allocatable-length strings will be implemented soon, this particular problem will go away.

[joseph-krahn]

It is possible to write a pure C_ASSOCIATED function in C, without any hacks, unless there are some restrictions on PURE C functions that I am unaware of. It should be possible to write a generic C_LOC function with specific C functions for every possible type for a given compiler, with the exception that strings of len>1 have to use the specific name to force sequence association. If a Fortran compiler has the ability to inline C functions, it would be just as good as built-in pure functions.

[Hirchert__Kurt_W]

MADsblionel:

I think that, yes, an implementation making C_LOC pure would be a nonconforming implementation.

Most of the time, Steve gets details like this right, but I believe that in this particular case, he was wrong. If I haven't forgotten some important detail about PURE,
a) there are constraints on what can appear inside a pure procedure written in Fortran, and
b) there are constraints on some procedure usage that requires the procedure to be pure, but
c) there are no rules about procedure usage that would require a particular procedure not to be pure.

From this, I draw the following conclusions:
1) A standard-conforming compiler is permitted to supply a C_LOC that is pure.
2) A standard-conforming program is not permitted to depend on C_LOC being pure.
3) Consequently, a standard-conforming compiler supplying a pure C_LOC would be required to identify such program usage as nonconforming.

That last requirement means that making C_LOC pure is more expensive than one might first imagine.

-Kurt

[joseph-krahn]

hirchert:

...
From this, I draw the following conclusions:
1) A standard-conforming compiler is permitted to supply a C_LOC that is pure.
2) A standard-conforming program is not permitted to depend on C_LOC being pure.
3) Consequently, a standard-conforming compiler supplying a pure C_LOC would be required to identify such program usage as nonconforming.

That last requirement means that making C_LOC pure is more expensive than one might first imagine.

-Kurt

If conclusion 1 above is correct, then I would consider depending on this feature more like depending on a specific kind of real number, or some other processor-dependent feature. There are many features that are explicitly defined as processor-dependent. Writing code that depends on such a feature does not make in non-standard, it just makes it non-portable, right?

If so, then supplyiung a pure C_LOC (and C_associated, etc.) would be permitted, but maby not a useful feature unless most or all Fortran compilers also decided on this convention.

Joe

[Steven_L_Intel1]

Kurt is generally correct. On further consideration, I suppose a compiler that supplied C_LOC as PURE would be standard-conforming, but would probably need a way to diagnose the use of C_LOC in a context where PURE was required.

Joe is also correct - a program that depends on an extension is non-portable. If the extension is not common, then it's probably worth avoiding unless you absolutely can't do without it.