Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Hi Kevin,

the problem is that this function is defined in socket.c and the 
structures
I'm interested in are SCTP specific. As far as I understood the comments
on the list it is not appropriate that SCTP stuff is used that fil (or
in guile at all).

Since the set/getsockopt function does not reference any specific 
structure
it would be a possibility of have it provided as generic as it is in C 
and
I would write some scheme functions to transfer the SCTP specific data
into the generic one. This would allow me to provide a C based module to
provide SCTP functionality without using my own version guile which I
want to avoid, because it is difficult for me to test all the platforms.

BTW, do you know how handle a function like

SCM_DEFINE (net_sctp_recvmsg, "sctp-recvmsg!", 2, 2, 0,
            (SCM sock, SCM str, SCM start, SCM end),
            "Return data from the socket port @var{sock} and also\n"
....
            "descriptor: any unread buffered port data is ignored.")
#define FUNC_NAME s_net_sctp_recvmsg
{
  int rv;
....
  return scm_list_4 (SCM_MAKINUM (rv), address, SCM_MAKINUM (flg), 
s_sinfo);
}
#undef FUNC_NAME

in a module? I have not found an example for C based modules for guile 
yet.
Everything distributed with guile is scheme based, I think.

Best regards
Michael

On Aug 23, 2004, at 2:58 AM, Kevin Ryde wrote:

> Michael Tuexen <address@hidden> writes:
> > Could the setsockopt and getsockopt functions be extended such that
> > they support an arbitrary length opt_value?
>
> The best is for the guile code to understand the data passed so it can
> do a sensible conversion.  You'll have to say what you're trying to
> use.