#11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by xnyhps): I hacked around with this a bit, these are my findings: * `ByteArray#` is represented as `StgArrBytes`, which includes a 1 word header and 1 word to indicate the size and is word aligned. This may be very convenient for things that want to use static `ByteArray#`s, but for usual string literals it sounds quite wasteful: on x86-64 it would require 24 bytes of padding to store a one-character string, instead of 2 for a zero-terminated string. (The alignment changes of #9577 would conflict with this, but it should still be possible to mark the sections as mergeable.) Considering that, and the existence of `byteArrayContents#`, I think it would be preferable to introduce a new primitive type `String#` that is used ''only'' for string literals. * Whichever different type `""#` gets, bootstrapping the compiler becomes tricky: the template for both Alex and Happy defines `""#` literals. What makes it worse is that this means stage 1 and stage 2 need a different template. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11312#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler