#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower | Owner:
Type: bug | Status: closed
Priority: high| Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: patch
Priority: high |Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: patch
Priority: high |Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: new
Priority: high |Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: new
Priority: high |Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower|Owner: igloo
Type: bug | Status: new
Priority: high |Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower|Owner:
Type: bug | Status: new
Priority: high |Milestone
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal| Component
#4901: Possible bug in GHCi archive loading:
-+--
Reporter: batterseapower| Owner:
Type: bug | Status: new
Priority: normal| Component
#3365: Bug in GHCi, 'impossible' happened
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 6.10.3
#3366: Bug in GHCi, 'impossible' happened
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 6.10.3
#3366: Bug in GHCi, 'impossible' happened
---+
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal |Milestone
#3365: Bug in GHCi, 'impossible' happened
---+
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal |Milestone
I encountered bug in ghci (in version 6.4.2 from gentoo and in latest binary
package 6.6.1 from www.haskell.org ).
Bug is:
*Main 3492928512*3492928512
-6246194483767017472
I'm using 64bit athlon.
(result is correct on 32 bits processors).
--
Przemysław Uznański
On Sun, May 06, 2007 at 04:33:22PM +0200, Przemyslaw Uznanski wrote:
I encountered bug in ghci (in version 6.4.2 from gentoo and in latest binary
package 6.6.1 from www.haskell.org ).
Bug is:
*Main 3492928512*3492928512
-6246194483767017472
I'm using 64bit athlon.
(result is correct on 32
Hi,
This is a bug which has been in GHCi from the beginning.
Bug
===
GHCi interprets a module while the compiled version is
present and up-to-date.
Details
===
When I (for example) have the following module structure:
module A where
...
module B where
import
Hi,
I discovered two bugs in GHCi. I am using GHC5.02 on
Linux.
The first bug has been there for some time now. If I start
GHCi with a module `A.hs', which either does not exist
itself, or which includes modules that not exist, then GHCi
terminates with an error message. This is rather
I discovered two bugs in GHCi. I am using GHC5.02 on
Linux.
The first bug has been there for some time now. If I start
GHCi with a module `A.hs', which either does not exist
itself, or which includes modules that not exist, then GHCi
terminates with an error message. This is rather
Hello all,
I have been using GHCi now for some time. There is one bug
that keeps coming back.
When I press control-C during the evaluation of an
expression, I get back to the prompt, and GHCi says:
Interrupted.
I make some changes to my files, and type :r, then GHCi
says:
Interrupted.
| I came across a VERY STRANGE bug in GHCi. It is difficult to pin down.
|
| I send a couple of modules. Running main in the module
| called Toggle, generates a file called system.galf. This
| is wrong!
|
| At line 14, it says bool(true).. To generate this, it must
| use definitions from
I attached a fix which will NOT source a suspicious file and print out
a warning. Could anyone with Wintendo please confirm that the Posix-stuff
doesn't break anything for them?
--
Abstrakte Syntaxträume.
Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME
--- ghci/InteractiveUI.orig Mon Apr
The problem is with directories like /tmp, or more generally
directories, which are not under the user's immediate control.
$ echo ':! some-evil-script.sh' /tmp/.ghci
Then wait, until somebody steps into the boobie trap: if one cd's to
/tmp and executes ghci (to test stuff, for
So, I think a safe solution is to ensure that the .ghci file belongs
to the user. Checking for decent permissions would increase security,
but well, IMO it's the users' fault, if he creates a 777 .ghci :-P
I've thought about this a bit more. It's not enough to just check the
owner and
To: Michael Weber; GHC Bugs list
Cc: Michal Politowski; [EMAIL PROTECTED]
Subject: RE: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]
So, I think a safe solution is to ensure that the .ghci file belongs
to the user. Checking for decent permissions would
increase security,
but well
On Mon, Apr 30, 2001 at 12:19:32 +0100, Simon Marlow wrote:
So, I think a safe solution is to ensure that the .ghci file belongs
to the user. Checking for decent permissions would increase security,
but well, IMO it's the users' fault, if he creates a 777 .ghci :-P
I've thought about
[mailto:[EMAIL PROTECTED]]
Sent: 30 April 2001 12:20
To: Michael Weber; GHC Bugs list
Cc: Michal Politowski; [EMAIL PROTECTED]
Subject: RE: [Fwd: Bug#94739: ./.ghci -- isn't it dangerous?]
So, I think a safe solution is to ensure that the .ghci
file belongs
to the user. Checking
| On Mon, Apr 30, 2001 at 12:19:32 +0100, Simon Marlow wrote:
| So, I think a safe solution is to ensure that the .ghci
| file belongs
| to the user. Checking for decent permissions would increase
| security, but well, IMO it's the users' fault, if he
| creates a 777
| .ghci :-P
|
In local.glasgow-haskell-bugs, you wrote:
fstat() (this is one reason why using access() is generally
discouraged). Using fstat() isn't particularly convenient from Haskell
- there's Posix.getFdStatus, but we'd have to use the Posix openFile
interface and fdToHandle. Alternatively we also can
In local.glasgow-haskell-bugs, you wrote:
fstat() (this is one reason why using access() is generally
discouraged). Using fstat() isn't particularly convenient
from Haskell
- there's Posix.getFdStatus, but we'd have to use the Posix openFile
interface and fdToHandle. Alternatively we
Mon, 30 Apr 2001 13:57:46 +0200, Michael Weber [EMAIL PROTECTED]
pisze:
If user X writes/modifies ./.ghci, then it gets the ownership of X,
doesn't it?
No.
[qrczak ~]$ ls -l 1
-rw-rw-rw-1 martabin 3775 kwi 30 15:21 1
[qrczak ~]$ echo foo 1
[qrczak ~]$ ls -l 1
-rw-rw-rw-
I agree that this feature is dangerous. I would prefer it be turned off
by default and an option given to enable it. Better yet, why not turn
it off altogether and add a builtin command that sources another file.
That way, users could add:
:source ./.ghci
to their $HOME/.ghci file to get
Matt Harden wrote:
...why not ... add a builtin command that sources another file.
How embarrassing...
:def source readFile
:-)
Now I definitely want the automatic sourcing of ./.ghci turned off; I
can already create a safer alternative myself.
Thanks,
Matt Harden
I mean:
:def source IO.readFile
Matt Harden wrote:
Matt Harden wrote:
...why not ... add a builtin command that sources another file.
How embarrassing...
:def source readFile
:-)
Now I definitely want the automatic sourcing of ./.ghci turned off; I
can already create a
of the file then
even though others may use the directory.
Regards,
Andy.
-Original Message-
From: Matt Harden [mailto:[EMAIL PROTECTED]]
Sent: 27 April 2001 01:27
To: Michael Weber
Cc: GHC Bugs list; Michal Politowski; [EMAIL PROTECTED]
Subject: Re: [Fwd: Bug#94739: ./.ghci -- isn't
* BENNETT,ANDY (HP-Unitedkingdom,ex1) [EMAIL PROTECTED] [2001-04-27T15:10+0100]:
While I agree that there is a potential security hole, I think it is
something that you could possibly tackle with the OS security mechanisms. I
don't know much about Windows, or other Unix platforms, but if they
Please, preserve the Cc: when replying.
- Forwarded message from Michal Politowski [EMAIL PROTECTED] -
Date: Sat, 21 Apr 2001 18:57:01 +0200
From: Michal Politowski [EMAIL PROTECTED]
Subject: Bug#94739: ./.ghci -- isn't it dangerous?
To: Debian Bug Tracking System [EMAIL PROTECTED
36 matches
Mail list logo