1 = 1024

[mattsdad]

I recently had a literal value, 1, that I passed into a subroutine as an INTENT(IN) argument . I erroneously passed that argument into another subroutine that changed its value. When I made another call later in the main program with theliteral value, 1, the value that was received by that subroutine was 1024. It was easy enough to find the error in the debugger, but two questions linger.

Whywas the subroutine with the INTENT(IN) argument able to use that argument in another subroutine call where the argument was INTENT(OUT)?

How could a literal constant have a different value than its literal value?

[Steven_L_Intel1]

What version of the compiler are you using? That the literal 1 changed its value should not be possible in 9.0 or later.

As for the INTENT - if the caller of the routine with INTENT(OUT) did not see an explicit interface, then it had no way of knowing it was disallowed.

[jparsly]

How could a literal constant have a different value than its literal value?

Constants are often implemented in a way that makes them work pretty much as

automatically created scalar variables that have a value assigned ahead of time.

The constant has a specific memory location assigned to it, and every time the

constant is needed it is loaded from that location.

So if I say:

x = 2.

call sub(2.)

The compiler is likely to create a single memory location in which the value of 2. is stored

and it will refer to this memory location any time is needs a copy of the constant 2.

When I call my subroutine:

call sub(2.)

it is pretty common that what gets passed to the subroutine is the address where 2. is

stored.

At the subroutine end:

subroutine sub(X)

the variable X is now associated with the address where 2. was stored

So if the subroutine code doesn't know any better and does something like this:

X = 5.

or

X = X + 1.

The result is that the storage location for the constant 2. gets a new value and every

subsequent reference to 2. gets the wrong result.

On some systems constants are stored in protected memory, so that an error occurs

if an attempt is made to make a change.

[Steven_L_Intel1]

As of version 9.0 (I think), constants are allocated in a read-only image section resulting in an access violation if you try to store to them. You can override this behavior with /assume:noprotect_constants which causes a temporary to be passed with the value.

[Jugoslav_Dujic]

MADsblionel:

As of version 9.0 (I think), constants are allocated in a read-only image section.

That would rather be CVF 6.5 or 6.6.

[Steven_L_Intel1]

DVF 6.0, but this feature was missing in ifort until version 9.0.