[GHC] #11312: GHC inlining primitive string literals can affect program output

[GHC]

#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:                    |
-------------------------------------+-------------------------------------
Changes (by simonpj):

 * cc: ekmett, core-libraries-committee (added)


Comment:

 Let's separate two things:

 * Top-level unboxed string literals: #8472
 * Not using `Addr#` for string literals: this ticket.

 Here's my summary for this ticket, after talking to Simon M.

 * It's plain wrong to use `Addr#` as the type of a string literal.  If we
 do so, there is no reliable way to compute equality for
 {{{
 data T = MkT Addr# deriving( Eq )
 }}}
   Since the `Addr#` might come from `malloc` or something, it must compare
 using equality on `Addr#`.  But then there is no guarantee that `MkT
 "foo"# == MkT "foo"#`.

 * So we need a new type for unlifted string literals, say `String#`.  It
 could be primitive, and that's what I'll assume for now.

 * Of course the underlying representation will be the same as `Addr#`.
 But there should be no operation `get :: String# -> Addr#` (except maybe
 in the IO monad), else it'd possible that `get "foo"#` might be not-equal
 to `get "foo"#`.

 * What operations do we need on `String#`?  Presumably at least
 {{{
 eqString#    :: String# -> String# -> Int#   -- Like eqChar#
 cmpString#   :: String# -> String# -> Int#   -- 3-way compare
 lenString#   :: String# -> Int#              -- Number of chars
 indexString# :: String# -> Int# -> Char#   -- Get the ith char
 }}}

 * NB: I'm deliberately not saying that the string is null-terminated.
 That's be up to the implementation of `String#`, provided it offered the
 above operations.  A better representation might be a record of a length
 and a blob of bytes.

 * Could `String#` simply be a `ByteArray#`?
 {{{
 type String# = ByteArray#
 }}}
   After all, `ByteArray#` already has primops `sizeOfByteArray#` and
 `indexCharArray#`.  We'd just need a way to have a statically-allocated
 `ByteArray#`, but that would be an excellent thing anyway.  e.g. I believe
 that Happy mis-uses literal strings to allow it to build a statically-
 allocated array.   Avoiding yet another primitive type would be a relief.

   See also #5218 and #9577

 * I'm not sure about how Unicode plays with all of this.

 * This would be a potentially breaking change for any code using unboxed
 string literals.  I'm copying the Core Libraries Committee

 I'd love someone to take this up.  there

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11312#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler