On Sun 13 Feb 2011 21:34, Noah Lavine writes:
> Here it is.
>
> On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine wrote:
>>> Yes, I think this is the thing to do.
>>>
>>> Can you rework your patch, Noah?
>>
>> Will do.
>>
Thanks, applied.
Andy
--
http://wingolog.org/
Here it is.
On Sun, Feb 13, 2011 at 3:10 PM, Noah Lavine wrote:
>> Yes, I think this is the thing to do.
>>
>> Can you rework your patch, Noah?
>
> Will do.
>
0001-Set-sockaddr_in.sin_len-field-when-it-exists.patch
Description: Binary data
> Yes, I think this is the thing to do.
>
> Can you rework your patch, Noah?
Will do.
On Sun 13 Feb 2011 19:34, Ken Raeburn writes:
>> The code I was fixing is creating a sockaddr_in, so in order to
>> use the sa_len field I would have had to cast a sockaddr_in to a
>> sockaddr, and it just seemed cleaner to use the sin_len field. It's no
>> big deal either way, though - this woul
On Sun 13 Feb 2011 03:22, Noah Lavine writes:
> The attached patch fixes the problem for me, and I believe zeroing
> some data structures before they're used won't hurt things for anyone
> else.
Applied, thanks for debugging this.
In the future, please give the function names in the commit logs
On Feb 13, 2011, at 08:55, Noah Lavine wrote:
> OS X, which I use, has a somewhat weird field-naming situation. The
> generic sockaddr structure has sa_len, but sockaddr_in has a sin_len
> field.
No, that's normal for a traditional C/UNIX API. Each structure's field names
use a prefix that's an
>> I suspect you'd do fine if you ditched the test for sockaddr.sin_len and
>> tested either sockaddr_in.sin_len or sockaddr.sa_len. (And I'd expect an OS
>> to be consistent as to whether the _len field exists for each of the various
>> socket address structures.)
Oh, and as for why I did thi
Hello,
On Sun, Feb 13, 2011 at 12:42 AM, Ken Raeburn wrote:
> What platforms have sin_len in the generic sockaddr structure? The one I've
> always seen is sa_len, and that's consistent with sa_family in terms of field
> name prefixes.
>
> sockaddr -> sa_
> sockaddr_in -> sin_
> so
What platforms have sin_len in the generic sockaddr structure? The one I've
always seen is sa_len, and that's consistent with sa_family in terms of field
name prefixes.
sockaddr -> sa_
sockaddr_in -> sin_
sockaddr_in6 -> sin6_
sockaddr_storage -> ss_
I suspect you'd do fine if
And this patch sets the sin_len member of struct sockaddr_in
correctly, even if it doesn't appear in struct sockaddr. It's not
needed to fix the previous bug, but it is more correct. Also it seems
like the sort of thing that could cause trouble later if it's not
fixed.
On Sat, Feb 12, 2011 at 9:22
Hello again,
The attached patch fixes the problem for me, and I believe zeroing
some data structures before they're used won't hurt things for anyone
else.
Noah
On Sat, Feb 12, 2011 at 8:45 PM, Noah Lavine wrote:
> Hi all,
>
> I think I have isolated the error (although in fact there are two
>
Hi all,
I think I have isolated the error (although in fact there are two
things that should be fixed).
I gdb'd Guile's executable and looked at the struct sockaddr just
before it was passed to bind. There were two mistakes.
First of all, that struct has an sa_len field which is supposed to
cont
Hi,
> #x49 is 73 :)
If I knew a facepalm emoticon, I would use it now. :)
> Could the lseek could be the problem?
Maybe, but I suspect not. My man page for lseek says that lseek will
fail with ESPIPE if it is called on a socket, and my errno.h defines
ESPIPE to be 29, which is the error we got.
Hi Noah,
On Sat 12 Feb 2011 22:35, Noah Lavine writes:
> socket(0x2, 0x1, 0x0) = 73 0; make a socket -
> INET family, SOCK_STREAM, internet protocol; we got one with
> descriptor 73
> fcntl(0x49, 0x3, 0x0) = 2 0 ; get flags for
> file de
Hello,
> I think that's just tracing the shell wrapper; use meta/uninstalled-env
> libtool --mode=execute dtruss guile to get a more proper trace.
Got it, thanks! Again there's a lot of output, but the most important
bit seems to be here (with some context):
;; Here Guile is finishing loading it
I tried the test program
(define addr (inet-aton "127.0.0.1"))
(define sockaddr (make-socket-address AF_INET addr 8080))
(define sock (socket PF_INET SOCK_STREAM 0))
(setsockopt sock SOL_SOCKET SO_REUSEADDR 1)
(bind sock sockaddr)
And got the same error. I also tried changing the port to 9000 and
On Sat 12 Feb 2011 21:47, Noah Lavine writes:
>> It would be interesting to see the output of a strace-like tool on both
>> the working Python program and the equivalent failing Guile program.
>> Apparently (according to the Interwebs), on OS X this tool is called
>> "dtruss".
>
> Sorry for the d
On Sat 12 Feb 2011 21:33, Noah Lavine writes:
>> Does guile --listen work? It appears to use a slightly different way to
>> set up the sockaddr.
>
> Oddly enough, it worked the first time I tried it (at least enough to
> get to a REPL - I didn't try to netcat over to it), but failed the
> second
Hello,
> It would be interesting to see the output of a strace-like tool on both
> the working Python program and the equivalent failing Guile program.
> Apparently (according to the Interwebs), on OS X this tool is called
> "dtruss".
Sorry for the delay in replying. I got the output of dtruss ea
Hello,
> Does guile --listen work? It appears to use a slightly different way to
> set up the sockaddr.
Oddly enough, it worked the first time I tried it (at least enough to
get to a REPL - I didn't try to netcat over to it), but failed the
second and third times.
> Also, can you file a bug in
On Mon 07 Feb 2011 07:28, Noah Lavine writes:
> I think there's a bug in Guile's Posix networking capabilities. I
> first noticed it a few days ago when I couldn't get the example web
> server to work on my system (Mac OS X 10.6). I was getting an error
> from the
Hello all,
I think there's a bug in Guile's Posix networking capabilities. I
first noticed it a few days ago when I couldn't get the example web
server to work on my system (Mac OS X 10.6). I was getting an error
from the bind command saying "can't assign requested add
Noah Lavine writes:
> Hello all,
>
> I think there's a bug in Guile's Posix networking capabilities. I
> first noticed it a few days ago when I couldn't get the example web
> server to work on my system (Mac OS X 10.6). I was getting an error
> from the
23 matches
Mail list logo
