additionally, the bug seems to work in GHC 7.8.4 too. On Thu, Jan 29, 2015 at 5:07 PM, Edward Kmett <ekm...@gmail.com> wrote:
> I personally would rather see this issue given the time to be resolved > correctly than rush to release 7.10 now because of a self-imposed deadline. > > An unsafeCoerce bug, especially one which affects SafeHaskell, pretty much > trumps all in my eyes. > > -Edward > > On Thu, Jan 29, 2015 at 2:54 PM, Austin Seipp <aus...@well-typed.com> > wrote: > >> After thinking about it a little, I'm fine with pushing the release out >> to March. I think #9858 is the more serious of our concerns vs a raging >> debate, too. >> >> My only concern really is dealing with the merging of such a patch. For >> example, if the patch to fix this is actually as wide ranging as we believe >> to the type hacker, I can definitely foresee a merge conflict, with, say, >> the recent -fwarn-redundant-constraints, which I've managed to leave out of >> 7.10 so far. >> >> In any case, with some more time, we can work those details out. >> >> On Thursday, January 29, 2015, Simon Peyton Jones <simo...@microsoft.com> >> wrote: >> >>> Friends >>> >>> In a call with a bunch of type hackers, we were discussing >>> >>> https://ghc.haskell.org/trac/ghc/ticket/9858 >>> >>> This is a pretty serious bug. It allows a malicious person to construct >>> his own unsafeCoerce, and so completely subverts Safe Haskell. >>> >>> Actually there are two bugs (see comment:19). The first is easily >>> fixed. But the second is not. >>> >>> We explored various quick fixes, but the real solution is not far out of >>> reach. It amounts to this: >>> >>> · Every data type is automatically in Typeable. No need to say >>> “deriving(Typeable)” or “AutoDeriveTypeable” (which would become deprecated) >>> >>> · In implementation terms, the constraint solver treats Typeable >>> specially, much as it already treats Coercible specially. >>> >>> It’s not a huge job. It’d probably take a couple of days of >>> implementation work, and some time for shaking out bugs and consequential >>> changes. The biggest thing might be simply working out implementation >>> design choices. (For example, there is a modest code-size cost to making >>> everything Typeable, esp because that includes the data constructors of the >>> type (which can be used in types, with DataKinds). Does that matter? >>> Should we provide a way to suppress it? If so, we’d also need a way to >>> express whether or not the Typable instance exists in the interface file.) >>> >>> But it is a substantial change that will touch a lot of lines of code. >>> Moreover, someone has to do it, and Iavor (who heroically volunteered) >>> happens to be travelling next week. >>> >>> So it’s really not the kind of thing we would usually do after RC2. >>> >>> But (a) it’s serious and, as it happens, (b) there is also the BBP >>> Prelude debate going on. >>> >>> Hence the question: should we simply delay 7.10 by, say, a month? >>> After all, the timetable is up to us. Doing so might give a bit more >>> breathing space to the BBP debate, which might allow time for reflection >>> and/or implementation of modest features to help the transition. (I know >>> that several are under discussion.) Plus, anyone waiting for 7.10 can >>> simply use RC2, which is pretty good. >>> >>> Would that be a relief to the BBP debate? Or any other opinions. >>> >>> Simon >>> >>> PS: I know, I know: there is endless pressure to delay releases to get >>> stuff in. If we give in to that pressure, we never make a release. But we >>> should know when to break our own rules. Perhaps this is such an occasion. >>> >> >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs