Silverfrost Forums

Welcome to our forums

Bug report

18 Apr 2012 10:47 #10027

Just a small bug:

      program test

      logical*2      L
      character*3    ext
      character*120  ifile

      ext   = 'jpg'
      ifile = 'test_image.tiff'
      call set_suffix@(ifile,ext,L)
      print*,ifile

      end

The suffix is not 'jpg' but 'jpgf' - so the old suffix should be deleted completely before adding the new one.

Regards - Wilfried

18 Apr 2012 8:00 #10028

I have now fixed this bug for the next release.

3 May 2012 9:06 #10084

Sorry, here's the next:

      program test

      character*10 string

      string = '  abcdefgh'
      call upcase@(adjustl(string))
      print*,string

      end

upcase@ didn't work together with adjustl.

Regards - Wilfried

3 May 2012 9:27 #10085

My understanding is that this behaves correctly.

adjustl is a function returning a character string. It does not change the argument. Hence the upper case is applied to the returned value which is then discarded. The character variable called string is left unchanged.

3 May 2012 10:01 #10086

Hmmm... My understanding was - according to the bracket rules - that first the string is adjusted to the left:

'abcdefgh' --> 'abcdefgh'

after that, this result is transformed to 'ABCDEFGH__'.

Thanks and regards - Wilfried

3 May 2012 4:38 #10089

Paul is correct, upcase@ is applied to a temporary variable which is discarded. You need to write it like this

    program test

      character*10 string

      string = '  abcdefgh'
      string = adjustl(string)
      call upcase@(string)
      print*,string

      end
4 May 2012 6:49 #10091

OK, I see. But it is not nice, and I don't understand why in this case it is impossible to 'work with brackets' like here:

      program test

      character*10 string,string2
      character*20 string3

      string  = '  abcdefgh'
      string2 = '    ABCD  '
      string3 = trim(adjustl(string2))//adjustl(string)
      print*,string3

      end

In this example, the term trim(adjustl(string2)) is handled in the usual way 'from inner to outer brackets': First, string2 is adjusted to the left, then the result is trimmed. That is the way I was expecting when I use upcase@(adjustl(string)).

Regards - Wilfried

4 May 2012 7:06 #10092

Here's the result, I wrote my own function doing that what i want:

      program test

      character*20  string
      character*120 ucase

      string  = '            abcdefgh'
      string  =  ucase(adjustl(string))
      print*,string
      end

      character function ucase(string) 

      integer*4      i,ic
      character*120  string

      do i = 1,len_trim(string) 
        ic = ichar(string(i:i)) 
        if (ic >= 97 .and. ic < 122) string(i:i) = char(ic-32)
        ucase(i:i) = string(i:i)
      end do
      end

Regards - Wilfried

4 May 2012 3:02 #10096

The reason TRIM(ADJUSTL(string)) works is because ADJUSTL and TRIM are functions. This sort of nesting functions as arguments inside another works because TRIM acts on the function result from ADJUSTL.

But UPCASE@ is a subroutine which expects a variable argument, so it can change it. If you write the following, the argument is not a variable.

CALL UPCASE@(ADJUSTL(STRING))

The solution, as you have discovered is to write your own function. But you didn't need to write your own case conversion, you could have just produced a 'function wrapper' for the UPCASE@ subroutine, e.g.

FUNCTION UPCASE(STRING)
   CHARACTER(LEN=*), INTENT(IN) :: STRING
   CHARACTER(LEN=LEN(STRING)) :: UPCASE
   UPCASE = STRING             ! Copy the string
   CALL UPCASE@(UPCASE)   ! Change it to uppercase
END FUNCTION

Note that this version automatically returns a string of the same length as STRING, whereas, your function always returns a string of 120 characters

Once you have this, you can write, for example,

S = '     hello' !< contains leading spaces
print *, UPCASE(ADJUSTL(S)) !< prints 'HELLO     '
print *, ADJUSTL(UPCASE(S)) !< prints 'HELLO     '
print *, TRIM(ADJUSTL(UPCASE(S))) !< prints 'HELLO'

Hope this helps, it might be useful to wrap other @ subroutines as well.

Regards David.

8 May 2012 9:13 #10104

David, just now I see your advise. Thanks a lot! It is a good idea to 'wrap' subroutines in the way you wrote.

Regards - Wilfried

Please login to reply.