[Bug fortran/37224] New: Request for C string literal syntax

[Bug fortran/37224] New: Request for C string literal syntax

[jkrahn at nc dot rr dot com]

Intel Fortran has a notation to specify C string literals by appending the
letter C at the end of the string. See here for an example:
http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/lref_for/source_files/pgcchcs.htm

It would be nice to have this, or something similar, in gfortran.

With Intel Fortran, it causes the string to interpret backslash sequences as in
C, and append a NUL character. I suggested to Intel the idea of implementing a
.C. unary string operator to do the same thing (I had seen it suggested on
c.l.f.), with the idea of trying to fit extensions into vendor intrinsic
modules instead of the traditional non-standard syntax approach. They said it
would be less standard-conforming, maybe because defined-unary operators cannot
be used in initialization expressions. They also stated that the C-suffix
approach was a well-establish extension, although neither gfortran nor Sun have
it.

I am requesting that gfortran support Intel's C-string notation to improve the
portability of C-interop code, if you think the extension is reasonable. It
would be nice for Fortran compiler developers to agree on some other common
convention, no matter what it is. One negative aspect of Intel's notation is
that it would be good to support C escape sequences independent of the NUL
terminator.

FYI: I also suggested that they look into gfortran's work on implementing new
character kinds such as UTF-8. That will also be very useful for reliable C
interop.


-- 
           Summary: Request for C string literal syntax
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jkrahn at nc dot rr dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224

[Bug fortran/37224] Request for C string literal syntax

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-08-24 19:45 -------
gfortran does have -fbackslash that enables c-style interpretation of backslash
characters in strings.

With the Intel approach, the code will not compile without error by a standard
conforming compiler.  I would not consider that portable at all.

At least with gfortran, the program will compile with or without the
-fbackslash.

I am sure there are more portable ways to accomplish these things.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224

[Bug fortran/37224] Request for C string literal syntax

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2008-08-24 20:26 -------
> FYI: I also suggested that they look into gfortran's work on implementing new
> character kinds such as UTF-8.

That part is defined in the Fortran 2003 standard (optional) and the
almost-ISO-approved Fortran 2008 (mandatory) thus I expect that Intel will get
it sooner or later as well.

Regarding the "..."C syntax: I don't quite see why using -fbackslash is not
enough plus for zero terminating a string:
   character, parameter :: NUL = achar(0)
then one can use:

  str = "A C-like terminated string"//NUL

which should work with all Fortran compilers. And if one wants to use C escape
sequences, one can use the -fbackslash option in gfortran and the -assume bscc
option of ifort.

Or one uses instead the predefined values of Fortran 2003 (though their names
are a bit long):

"This is followed by a
tab"//C_HORIZONTAL_TAB//"*bing*"//C_ALERT//C_NEW_LINE//C_NULL_CHAR

That should also work with all (C-binding supporting) compilers. One could also
define shorter names, e.g. C_TAB = C_HORIZONTAL_TAB, C_NL = C_NEW_LINE etc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224

[Bug fortran/37224] Request for C string literal syntax

[dfranke at gcc dot gnu dot org]

------- Comment #3 from dfranke at gcc dot gnu dot org  2008-12-09 22:26 -------
Given comments #1 and #2, this is a WONTFIX. 
Closing. Please reopen if this should be further discussed.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37224