#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