Use of SIZEOF as actual argument

[Les_Neilson]

According to the Intel Fortran documentation SIZEOF cannot be passed as an actual argument.

I helped fix a bug the other day where one of the items changed was a call with SIZEOF as an argument. There were other code changesmade at thesame timebut I wish we'd thought of changing one thing at a time to see if this fixed the original bug.However I have alsocome across a few sample codes elsewhere (eg in this forum)whichalso use SIZEOF as an actual argument eg:

call ZeroMemory(LOC(a), SIZEOF(a))

Did the code just work fortuitously or is the documentation wrong?

Les

[anthonyrichards]

Could it mean making it EXTERNAL and sending its name as an argument is disallowed?

[Steven_L_Intel1]

Correct. You cannot pass the intrinsic function SIZEOF itself as an argument. What you have shown is an expression that happens to use SIZEOF, and that's fine.

[jimdempseyatthecove]

Steve,

Perhaps you can suggest that the documentation clarifies this. The current documentation has "It cannot be passed as an actual argument" which leads one to assume "it cannot be used in the argument list", in particular where it would create a temporary variable on the stack and then pass that as the reference to the function or subroutine.

I guess the compiler would have to be careful not to pass the address in the descriptor to the sizeon something like SIZE(A) such that the subroutine called cannot use the reference to alter the descriptor. The compiler should create the stack temporary and pass the address of that (assuming by reference is the calling convention).

Jim

[Steven_L_Intel1]

SIZEOF is something the compiler knows at compile-time and there's no way to call it with an arbitrary argument at run-time.

In Fortran, passing a procedure as an actual argument has a specific meaning- it doesn't seem ambiguous to me, but I'll ask our writers to think about it.

[jimdempseyatthecove]

This is a case where the developer is too close to the product to write the documentation for those not intimately familiar with the product. The particular issue here is the product developer has a different frame of reference in interpreting the documentation than that of the typical user. The typical user, in reading the documentation, will (as experienced by the original poster of this thread or by me with 35 years of programming) often interpret the documentation differently. In this case the interpretation was (incorrect as it was) an intrinsic cannot be used in an argument list. While an intrinsic may be usedas a function to produce a result (as temp) and subsequently the result passed as an argument.

The current documentation is correct. Once you know thenuance of if the intrinsic function representseither an expression or an attempt at producing the address of the intrinsic (which doesn't exist) it all becomes clear. However, until the connection is made the new user will continue to assume that the intrinsic cannotbe present in an argument list. As a favor to the new user it would be appreciated to add a sentence to this effect (to all places listing the restriction on use of intrinsic as argument).

I wonder how many times an explicit temp was used when none need have been used, And as a consequence, the reuse of a temp (e.g. TEMP) introduced a bug into the program.

Jim Dempsey

[TimP]

In 40 years of Fortran programming, I've never seen anyone pass a vendor-specific intrinsic function as an argument. Maybe it didn't occur to the documentation writers that this might be tried. I don't think the original post makes it clear what was done, what diagnostic message came out when, and what should be done to improve diagnosis.

I suppose IMPLICIT NONE or equivalent should throw a compile time error when an argument is intended as a function argument, but is not declared. Further, itmight be possible to give a compile time warning whenan intrinsic (standard or vendor-specific)is used incorrectly as an argument in CALL, when IMPLICIT NONE is in effect. I wouldhave thought that MODULE or INTERFACE should enable such an error to be caught at compile time.

[Les_Neilson]

Thanks all for explanation and comment.

I did indeed misread the difference betweenpassing the function and passing the result ofthe function. I was too busy trying to help solve the urgent bug fix to think properly and then got stuck in that mindset.

The original error was caused by a character string not being initialised correctly, only a substring of itwas initialised, (hence it was not padded with blanks as the original author had presumablyhoped) "scan" from the far end of the string found what it was looking for (/) in the garbage.All of this happening in a chain of calls in unfamiliar code and needing a fix asap. Ah the joys of maintenance.

Les