[GHC] #12516: Preprocessing: no way to portably use stringize and string concatenation

22 Aug 2016

      #12516: Preprocessing: no way to portably use stringize and string concatenation
-------------------------------------+-------------------------------------
           Reporter:  harendra       |             Owner:
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 To reduce boilerplate code in an FFI implementation file I am trying to
 use the stringizing and string concatenation features of the C
 preprocessor.  But it seems there is no portable way to do that. I am
 listing what I tried below:

 1. Using stringizing and string concatenation in traditional mode
 (https://gcc.gnu.org/onlinedocs/cpp/Traditional-macros.html). ghc uses cpp
 in traditional mode by passing `-traditional`. The behavior of
 `-traditional` mode is not consistent across gcc and clang. While gnu cpp
 supports stringizing and string concatenation in traditional mode clang
 cpp does not support it.
 2. Disable traditional mode on the given file. There is no way to disable
 `-traditional` via `-optP` since it only appends new options to the
 preprocessor and does not override the old ones.
 3. There is an issue in using the clang cpp via `-pgmP cpp`. clang cpp
 does not accept a space between `-I` flag and the include directory. For
 example `cpp -I .` fails with `clang: error: no such file or directory:
 'c'`. ghc passes this flag with a space.
 4. Finally, using cc as a preprocessor worked for me: `{-# OPTIONS_GHC
 -pgmP cc -optP -E -optP -undef -optP -std=c89 #-}`. But This relies on cc
 being in `PATH` and always pointing to a compiler which behaves in the way
 we want. In theory, cc may turn out to be different than the compiler and
 preprocessor actually used by ghc. But this still seems to be the best
 practical option and I am using this one.

 Possible solutions could be:
 * Use a native preprocessor, something like `cpphs`.
 * A temporary workaround could be to provide a way to override the
 preprocessor options (rather than appending to them) so that we can
 knowingly use the configured ghc preprocessor program without the
 traditional flag, something like `-optP--override`.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12516
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler