Wed, 3 Jan 2001 15:31:43 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> Which is all just my long-winded way of saying I agree with Simon
> that we should not do this. Even if f.e.d. could return nullFunPtr,
> we should not do this because we can express it better using a Maybe.
I retrieve t
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Wed, 3 Jan 2001 21:12:54 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > > Yes: me, for the readline library.
> >
> > Could you be more specific?
>
> typedef struct {...} KEYMAP_ENTRY;
> typedef KEYMAP_ENTRY *Keymap;
> typedef int
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> > > I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I
> > > once had to write
> > > when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr
> > > and it can be seen as consistent with free.
>
> This sort of behaviour is comon in C but I
> > I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I
> > once had to write
> > when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr
> > and it can be seen as consistent with free.
This sort of behaviour is comon in C but I think this is mostly because C has
such a weak type sys
On Wed, 3 Jan 2001, Fergus Henderson wrote:
> By "they", I mean the Haskell routines under discussion.
OK, I always thought that Haskell's FFI docs should document what they
assume about the C implementation which is not guaranteed by ISO/ANSI.
For example that pointers are physically amorphic,
On 03-Jan-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Wed, 3 Jan 2001 21:12:54 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > Well, if they are left, then at very least they should be
> > very clearly documented as being non-portable.
>
> They should, they aren't. Per
Wed, 3 Jan 2001 21:12:54 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> Well, if they are left, then at very least they should be
> very clearly documented as being non-portable.
They should, they aren't. Perl internally relies on the fact that
memsetting all bits to 0 produces null pointe
On 03-Jan-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Wed, 03 Jan 2001 12:27:20 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]>
>pisze:
>
> > This means that we should not provide
> >
> > castFunPtrToPtr :: FunPtr a -> Ptr b
> > castPtrToFunPtr :: Ptr a -> FunPtr b
Wed, 03 Jan 2001 12:27:20 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> This means that we should not provide
>
> castFunPtrToPtr :: FunPtr a -> Ptr b
> castPtrToFunPtr :: Ptr a -> FunPtr b
It does not mean that, because existing C libraries are usually
non-portable and s
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 02-Jan-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> >
> > and even the ability to cast between data pointers and function pointers
> > is described as a common non-standard extension in ISO/ANSI C99.
>
> That's true. ANSI/ISO C do
On 02-Jan-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
>
> Null function pointers are a non-portable concept - ANSI C does not have
> them, only null data pointers. But many existing C interfaces use them,
You're mistaken -- ANSI/ISO C definitely does have null function pointers.
On Tue, 2 Jan 2001, Simon Marlow wrote:
> > I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I
> > once had to write
> > when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr
> > and it can be seen as consistent with free.
>
> This makes sense if nullFunPtr is really a valid valu
> Tue, 02 Jan 2001 19:40:11 +1100, Manuel M. T. Chakravarty
> <[EMAIL PROTECTED]> pisze:
>
> > PS: It could be argued that `Ptr ()' can always be used
> > instead of `Addr' and that therefore we should do away
> > with `Addr' altogether. Opinions?
>
> I agree that Addr uses should be
On 02-Jan-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
>
> On IA-64 C function pointers are AFAIK twice as big as data pointers
> (16 bytes!), to hold a global data pointer associated with the module
> the function came from, which is a part of a model of dynamically
> linked librar
Tue, 02 Jan 2001 19:40:11 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> PS: It could be argued that `Ptr ()' can always be used
> instead of `Addr' and that therefore we should do away
> with `Addr' altogether. Opinions?
I agree that Addr uses should be replaced by Ptr an
I propose to deprecate `freeHaskellFunctionPtr' in Foreign.
Equivalent functionality is now available from
`Ptr.freeHaskellFunPtr'. Normally, we have all `Ptr'
functionality also in a variant for `Addr', but in this
case, this doesn't make sense in my opinion. The reaso
16 matches
Mail list logo
