[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> [AF_INET...]
> + c_address = scm_malloc (sizeof (struct sockaddr_in));
> + c_inet = (struct sockaddr_in *)c_address;
> +
> + c_inet->sin_addr.s_addr =
> + htonl (scm_to_ulong (SCM_SIMPLE_VECTOR_REF (address, 1)));
Lo
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> Regarding `sendto', I tested it informally as follows:
>
> An AF_UNIX socket can probably exercise that.
The attached patch does this (note that this patch only updated the test
itself; for the code, y
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Regarding `sendto', I tested it informally as follows:
An AF_UNIX socket can probably exercise that.
> I didn't test IPv6 stuff
Something using localhost would be good. I thought at one stage to
add "IN6ADDR_LOOPBACK" or something as a constant to
Hi Kevin,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Untested code cannot be accepted. AF_UNIX is easy, AF_INET6 might
> depend on the system. You'll need to make something for
> test-suite/tests/socket.test exercising each case, eventually.
I finally wrote test cases which actually helped me fi
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Again, I only tested AF_INET addresses and I didn't try `sendto' and
> `bind'.
Untested code cannot be accepted. AF_UNIX is easy, AF_INET6 might
depend on the system. You'll need to make something for
test-suite/tests/socket.test exercising each ca
Hi,
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Right. I followed your suggestion (with slight modifications, namely
> have an ADDRESS_SIZE output parameter for functions that return a
> pointer to `struct sockaddr') and updated my patch. However, the only
> thing I tested is `scm_from_sockad
Hi Marius,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Hmm, I think your patch mixes the two ways we have to express a socket
> address: one way is an argument convention used by connect, bind, and
> sendto; the other way is a vector with the relevant data inside, as
> returned by accept, getsoc
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Thanks for the input... */me scratches head* ... this is what the
> heathens call their "DLL hell", right?
Perhaps. In case it's relevant, I believe this may be why libtool
provides lt_dlmalloc, lt_dlrealloc, and lt_dlfree. See the libtool
info page
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Following this discussion, I propose the following addition which
> exposes the wrapping/unwrapping functions of `sockaddr' objects.
Hmm, I think your patch mixes the two ways we have to express a socket
address: one way is an argument convention used
Ken Raeburn <[EMAIL PROTECTED]> writes:
> I'm not an expert in this area, but my understanding is: [...]
Thanks for the input... */me scratches head* ... this is what the
heathens call their "DLL hell", right?
I would have to see a concrete patch to have a more concrete opinion.
Right now, I do
On Aug 20, 2005, at 08:40, Marius Vollmer wrote:
My decision at that time was that we assume that there is only one
malloc and one free.
Okay.
Basically, malloc and free referenced from a DLL, say libguile.dll,
may be different instances of the functions than the application or
other DLLs mig
Ken Raeburn <[EMAIL PROTECTED]> writes:
> This reminds me... was there ever a decision on the "call malloc and
> free from the same object on Windows" issue?
My decision at that time was that we assume that there is only one
malloc and one free.
> Basically, malloc and free referenced from a DLL
On Aug 19, 2005, at 03:57, Ludovic Courtès wrote:
+/* Return a newly-allocated `sockaddr' structure that reflects
ADDRESS, being
+ an address of family FAMILY, with the family-specific
parameters ARGS (see
+ the description of `connect' for details). The returned
structure may be
+ f
Hello,
It seems that the email below (<[EMAIL PROTECTED]>) got lost. Can
someone comment on this?
Thanks,
Ludovic.
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Marius Vollmer <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>>> Obviously, the best soluti
Hi,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> Obviously, the best solution would be to expose the relevant functions
>> to the user. :-)
>
> Yes, we should do that, following the scm_to and scm_from naming scheme.
Following this discussion, I
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Obviously, the best solution would be to expose the relevant functions
> to the user. :-)
Yes, we should do that, following the scm_to and scm_from naming scheme.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
_
Hi,
Most type wrapping/unwrapping methods that are used within Guile are not
exposed to the user, which is a pity. For example, `scm_addr_vector'
(in socket.c) which converts a `sockaddr' structure to its Scheme
representation (a vector) is defined as `static'. This leaves the C
programmer with
17 matches
Mail list logo
