Error: Rank mismatch in argument 'std' at (1) (scalar and rank-1)

If I change the definition of:


CHARACTER CARD1*(*)
To:
CHARACTER CARD1(*)

I get the error:

18 IF (RUZE(REPRESENT(1:7),STD(1:7)))THEN
                                1
Error: Rank mismatch in argument 'card2' at (1) (scalar and rank-1)

What do I do?

      LOGICAL FUNCTION RUZE(CARD1,CARD2)
      IMPLICIT NONE
      CHARACTER CARD1*(*),CARD2*(*)
      
      CARD1 = 'K'
      CARD2 = 'Q'
      RUZE = .true.
      
      RETURN 
      END
      
      SUBROUTINE MAKE_MOVE(STD)
        IMPLICIT NONE
        LOGICAL RUZE
        CHARACTER STD*(*)
        CHARACTER REPRESENT*10
        
        IF(RUZE(REPRESENT(1:7),STD(1:7)))THEN
         WRITE (*,*) 'STEP1 SUCCESSFUL'
        ENDIF
            
        RETURN
      END

Program PLAYING
 IMPLICIT NONE
 INTEGER MOVES
 PARAMETER (MOVES=100)
 CHARACTER*15 BIGMOVE(MOVES)
 CALL MAKE_MOVE(BIGMOVE)
End Program PLAYING

  gfortran -c -g play.f90 -o play.o
  gfortran -g play.o -o play.exe -lgfortran
   30 |  CALL MAKE_MOVE(BIGMOVE)
      |                1
Error: Rank mismatch in argument ‘std’ at (1) (scalar and rank-1) [-Werror=argument-mismatch]
f951: all warnings being treated as errors

You have already asked that (or very similar) question here.

1 Like

This thread is very difficult to follow and I’m not sure whether I understand what the actual question is.

The error in your original post is already discussed in Error: Rank mismatch in argument ‘cars’ at (1) (scalar and rank-1) and was apparently also resolved there. The follow up snippet seems like a different problem and therefore off-topic to this thread.

Generally, it will help readers of your thread to clearly state the goal you want to reach here beyond getting the code to compile.

2 Likes

I think @msz59 's explanation of the difference between “CHARACTER*() A" and "CHARACTER A()” at the end of that (long) thread is quite to the point, but otherwise I agree: please state the question or problem you have clearly, so that we do not have to guess. Also the error messages from the compiler should help you and in this particular case, with the previous thread in mind, they are rather clear.

That said, do feel free to ask questions. But posing a clear question does help a lot. Both us and you :slight_smile:

1 Like

The answer lies in your other thread (Error: IF clause at (1) requires a scalar LOGICAL expression).

  LOGICAL FUNCTION RUZE(CARD1,CARD2)
  IMPLICIT NONE
  CHARACTER CARD1*(*)
  CHARACTER(*) ::CARD2(:)  ! assumed-shape array, previously assumed-size

You provide one. The two options are 1) any procedure which calls RUZE should contain a block such as

INTERFACE
  LOGICAL FUNCTION RUZE(CARD1,CARD2)
    IMPLICIT NONE
    CHARACTER CARD1*(*)
    CHARACTER(*) ::CARD2(:)
  END FUNCTION
END INTERFACE

You can use an include statement if want to save yourself the typing. The better solution 2) is to define the interface (or the entire) procedure in a named module. Calling routines can then use that module.

Alternatively, you could get rid of the assumed-shape array (the one ending with (:)) and use some F77-conforming solution instead. Unfortunately, given the changes you are making, it’s almost impossible to figure out your intentions. Are CARD1 and CARD2 supposed to be arrays or scalars (single cards)?

@Giraffe, you have shown a small program with less than 100 lines of code, containing a couple of subprograms and with syntax errors that you report and ask for help in fixing. There are many different ways of making the program acceptable to the compiler, but none of them is worth even considering unless you describe what you are trying to accomplish with the program.

Putting the syntax errors aside, and assuming that the declarations, calls, etc., can be fixed, we still face the problem that the fixed program would do nothing useful. As far as I can see, the whole program can be replaced by the following two lines:

WRITE (*,*) 'STEP2 SUCCESSFUL'
END PROGRAM

In such circumstances, I am inclined to say that the program has no useful purpose, and it is not worthwhile to explore the impact of various syntax errors and confused and confusing mismatched variables, etc.

Your first goal should be to describe the purpose of the program and state your plan for implementing the steps to achieve that purpose, in English.