GHC: Ticket Query The Glasgow Haskell Compiler en-US GHC Trac 1.0.1 #2120: Arrays allow out-of-bounds indexes Sun, 24 Feb 2008 17:51:56 GMT amthrax <p> The array changes proposed and recently implemented for ticket <a class="closed ticket" href="" title="proposal: Make arrays safer (closed: fixed)">#1610</a> (Make arrays safer) strengthened the requirements on <tt>Ix</tt> instances, but weakened the requirements on array users. Specifically, array referencing now permits indexes that are <em>not</em> <tt>inRange</tt>. </p> <p> For example, </p> <pre class="wiki">import Data.Array.IArray b :: Array (Int,Int) Int b = listArray ((0,0), (3,3)) (repeat 0) main = do print (b ! (0,5)) -- SHOULD fail, but doesn't print (index (bounds b) (0,5)) -- DOES fail </pre><p> The first line in <tt>main</tt> <em>should</em> fail because the specified index is not <tt>inRange</tt>, but doesn't because the <tt>(!)</tt> operator (specifically <tt>Data.Array.Base.safeIndex</tt>) now uses <tt>unsafeIndex</tt> and simply checks that the resulting index is within the linearized bounds of the array. In this case, the unsafe index of (0,5) wraps aroung to the index of (1,1). </p> <p> A simple fix would be to use <tt>index</tt> instead of <tt>unsafeIndex</tt> in the implementation of <tt>Data.Array.Base.safeIndex</tt>. This would both require the user to use in-bounds references and would require <tt>Ix</tt> instances to return in-bounds indexes. </p> Results #3417: Data.Array.IO.hGetArray should be implemented. Thu, 06 Aug 2009 14:18:14 GMT int-e <p> This is a leftover from the IO library rewrite. Right now <tt>hGetArray</tt> is defined as <tt>undefined</tt>. </p> Results #2727: DiffArray performance unusable for advertized purpose Tue, 28 Oct 2008 00:38:21 GMT claus <p> (cf. this <a class="ext-link" href=""><span class="icon">​</span>ghc-users thread</a>) </p> <p> <tt>Data.Array.Diff.DiffArray</tt> is unusably slow. Sometimes even <tt>Data.Array.Array</tt> is faster in single-threaded use, defeating the purpose. The attached code tries to demonstrate the issue, if I got the single-threadedness via <tt>$!</tt> right (default compilation <tt>ghc --make SlowDiffArray.hs</tt> gives <tt>Array</tt>, build with <tt>-DUseDiff</tt> to get <tt>DiffArray</tt>). </p> <p> As I happened to have some older ghcs around, I tried those as well, and it seems the issue got worse around 6.8.3 (<tt>SlowDiffArrayA-&lt;version&gt;</tt>: Array; <tt>SlowDiffArrayDA-&lt;version&gt;</tt>: <a class="missing wiki">DiffArray?</a>): </p> <pre class="wiki">$ for i in *.exe ; do echo $i; time ./$i; done SlowDiffArrayA-61120081004.exe 9990001 real 0m0.307s user 0m0.015s sys 0m0.015s SlowDiffArrayA-641.exe 9990001 real 0m0.261s user 0m0.030s sys 0m0.000s SlowDiffArrayA-661.exe 9990001 real 0m0.260s user 0m0.015s sys 0m0.000s SlowDiffArrayA-683.exe 9990001 real 0m0.232s user 0m0.015s sys 0m0.000s SlowDiffArrayDA-61120081004.exe 9990001 real 0m12.932s user 0m0.031s sys 0m0.000s SlowDiffArrayDA-641.exe 9990001 real 0m7.114s user 0m0.015s sys 0m0.016s SlowDiffArrayDA-661.exe 9990001 real 0m5.774s user 0m0.015s sys 0m0.015s SlowDiffArrayDA-683.exe 9990001 real 0m12.814s user 0m0.015s sys 0m0.000s </pre><p> (measured on Pentium M 760, 2GHz, Windows XP) </p> <p> [the majority of the issue probably lies in the <tt>DiffArray</tt> implementation, hence component <tt>libraries</tt>, but it seems that compiler and runtime system also play a role] </p> Results #3083: Win32 package should bind SHGetFolderPath Wed, 11 Mar 2009 12:04:59 GMT duncan <p> Currently Cabal binds this function so that we can find the "Program Files" directory on Windows: </p> <pre class="wiki">foreign import stdcall unsafe "shlobj.h SHGetFolderPathA" c_SHGetFolderPath :: Ptr () -&gt; CInt -&gt; Ptr () -&gt; CInt -&gt; CString -&gt; IO CInt </pre><p> This is fine except that it does not work in ghci because we have no way to tell ghci that it would need to link to <tt>shell32.dll</tt>. As it happens we do not have to tell the static linker to use <tt>shell32.dll</tt> because it appears to link to it by default. This of course means that <tt>runghc Setup</tt> does not work on Windows for Cabal itself which trips up many users. The fact that the <tt>README</tt> tells people to use <tt>ghc --make Setup</tt> instead doesn't help a great deal. See <a class="ext-link" href=""><span class="icon">​</span>Cabal ticket #325</a> </p> <p> What would be nice is if the Win32 package would bind <a class="ext-link" href=""><span class="icon">​</span>SHGetFolderPath</a>. Then we just import it from the Win32 package and it'll work in ghci. Apparently, according to MSDN, this function is technically deprecated, however the replacement <a class="ext-link" href=""><span class="icon">​</span>SHGetKnownFolderPath</a> is only available in Vista and later so we probably need to bind it anyway. Note that <tt>SHGetFolderPath</tt> is in <tt>shell32.dll</tt> except on Windows 2000 which include it in <tt>SHFolder.dll</tt> which come with IE4 and later. </p> Results #3094: Some GHC.* module should export word size and heap object header size Fri, 13 Mar 2009 17:13:18 GMT duncan <p> Some code, like <tt>bytestring</tt>, uses magic constants to help it decide how much memory to allocate. This is not a correctness issue, just an optimisation one. It allows the <tt>bytestring</tt> package to allocate buffers that make optimal use of ghc's pinned allocator strategy which has to use a whole number of 4k pages. The magic is in subtracting the heap object header size: </p> <pre class="wiki">-- | Currently set to 32k, less the memory management overhead defaultChunkSize :: Int defaultChunkSize = 32 * k - chunkOverhead where k = 1024 -- | Currently set to 4k, less the memory management overhead smallChunkSize :: Int smallChunkSize = 4 * k - chunkOverhead where k = 1024 -- | The memory management overhead. Currently this is tuned for GHC only. chunkOverhead :: Int chunkOverhead = 2 * sizeOf (undefined :: Int) </pre><p> This works for normal builds but for profiling builds it is a couple words off which wastes memory. It would also be be nice if it did not have to use magic constants but if it could import them from <tt>GHC.Exts</tt> or something. </p> <p> We would want: </p> <ul><li>Heap object header size, in words (currently 2 normally or 4 for profiling) </li><li>Word size (4 or 8 bytes) </li><li>Heap block size (currently 4k) </li></ul><p> These should all be actual Haskell constants so that they inline perfectly into calculations with no runtime overhead. The heap object header size is obviously different between profiling and normal, however this works out ok because we have to recompile for profiling anyway. </p> Results #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue Mon, 18 May 2009 15:34:22 GMT binarin <p> regSetStringValue calls regSetValueEx with length of value in characters, not in bytes. Due to this only first half of value is written to registry. </p> Results #3257: System.Exit.exitWith exits current thread, not program Sun, 24 May 2009 05:09:11 GMT Bart Massey <p> The documentation for System.Exit is a bit ambiguous about what the exitWith function exits from, but IMHO the most natural inference is that it exits the process from within which it is called. However, it currently does not necessarily do so; if called from a forkIO'ed thread, it will raise the exit exception in that thread rather than the "main thread" of the process. </p> <p> IMHO it would be best to change this behavior, but failing that it ought to at least be better documented. For now, I am manually throwing an ExitCode to the main thread as a workaround. </p> Results