Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Intel Customer Support will be observing the Martin Luther King holiday on Monday, Jan. 17, and will return on Tues. Jan. 18.
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
26852 Discussions

-asume bscc is broken (ifort ver 15.0.2)

Marc__Jan
Beginner
138 Views
Following program: 

      program bsccbroken                                                                                                                                                         

      write(*,*) '\"ABCDEF\"'
      write(*,*) '\"ABCDEF\"\0'
      write(*,*) '\"#\"'
      write(*,*) '\"#\"\0'

      end program bsccbroken

When compiled with ifort version 15.0.2:

ifort -assume bscc -warn all -g -o bscc bscc.f

Produces following output:

[bma@localhost f]$ ./bscc
 "ABCDEF"
 "ABCDEF
 "#"
 "#
 

Please notice that closing quote is not included when \0 is appended to the end of the string. I work with large legacy code base where those closing zero bytes (\0) are very often included to ensure interoperability with C APIs.

While using IBM fortran xlf90 produces expected result:

$ xlf90 -o bscc bscc.f
** bsccbroken   === End of Compilation 1 ===
1501-510  Compilation successful for file bscc.f.
$ ./bscc
 "ABCDEF"
 "ABCDEF"
 "#"
 "#"
 

Is it well known problem with -assume bscc option? Is there a patch for this? Is this behavior different in newer versions of Composer Studio?

Thanks in advance for any information.

 

0 Kudos
2 Replies
Steve_Lionel
Black Belt Retired Employee
138 Views

The problem here is that Intel Fortran doesn't recognize \" as a valid escape sequence (reference). The manual says:

If a string contains an escape sequence that isn't in this table, the backslash is ignored.

I admit it is a bit weird that it throws away the \0 in this case - that may be a bug in itself. If you don't have any unrecognized sequences, then \0 is processed properly.

I was able to reproduce this behavior in 19.0.5.

Marc__Jan
Beginner
138 Views

Thank you for your response. For the time being I fixed the application code by removing redundant backslash before ".

Reply