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
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Tue, 2 Jan 2001 22:28:02 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
>
> > Doing it in a separate tool will lose efficiency in some important
> > cases. If the compiler is compiling via C, then it can insert
> > inline C code directl
Fergus Henderson <[EMAIL PROTECTED]> wrote,
> On 02-Jan-2001, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> > [This comment is a bit late, I know...]
> >
> > [EMAIL PROTECTED] wrote,
> >
> > > Fergus writes, triggered by my suggestion of "foreign value":
> > >
> > > > Mercury supports
Tue, 2 Jan 2001 22:28:02 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> Doing it in a separate tool will lose efficiency in some important
> cases. If the compiler is compiling via C, then it can insert
> inline C code directly in the generated code, and thus get
> inlining. But I think a
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, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> [This comment is a bit late, I know...]
>
> [EMAIL PROTECTED] wrote,
>
> > Fergus writes, triggered by my suggestion of "foreign value":
> >
> > > Mercury supports this using `foreign_decls' and `foreign_code' pragmas.
> >
>
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
[This comment is a bit late, I know...]
[EMAIL PROTECTED] wrote,
> Fergus writes, triggered by my suggestion of "foreign value":
>
> > Mercury supports this using `foreign_decls' and `foreign_code' pragmas.
>
> I refrained from proposing this in an earlier mail, but I've been
> thinking about
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 reason is
that `Addr' is there
12 matches
Mail list logo
