Re: Bug in Guile's Posix Networking

[Andreas Rottmann]

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 bind command saying "can't assign requested address". I
> assumed it was a system configuration problem until I discovered that
> an equivalent Python program could bind a socket without trouble.
>
> The full story is at
> http://serverfault.com/questions/231941/why-cant-i-bind-to-127-0-0-1-on-mac-os-x
> (I know the Python program listed is not quite identical to the Scheme
> one, but I tried it with an actually identical Scheme program and
> still got the same error.) Interestingly enough, I was able to bind a
> socket in Guile if I specified INADDR_ANY as its address instead of
> 127.0.0.1.
>
> I hope to work on this soon, but I thought I'd ask on this list if
> anyone has an idea what might be causing this.
>
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".

Regards, Rotty
-- 
Andreas Rottmann -- 

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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 bind command saying "can't assign requested address". I
> assumed it was a system configuration problem until I discovered that
> an equivalent Python program could bind a socket without trouble.

Does guile --listen work?  It appears to use a slightly different way to
set up the sockaddr.

I was able to reproduce this bug on a machine at work, but didn't have
time to figure out what was the deal.

Also, can you file a bug in the tracker for this?

Thanks,

Andy
-- 
http://wingolog.org/

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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 the tracker for this?

I will do this right now.

Noah

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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 easily
enough, but I don't know how to interpret it, and a lot of it seems to
be noise from initialization. I was hoping to learn how to interpret
it, but had no luck so far, so here is Guile's dtruss output. I can
send Python's output too if you would like, but it's similarly long:


SYSCALL(args)= return
getpid(0x7FFF5FBFF870, 0x7FE00050, 0x0)  = 85226 0
open_nocancel("/dev/urandom\0", 0x0, 0x0)= 3 0
read_nocancel(0x3,
"Y=\337\353\244[\375\214!\370\261\317%\224\"2n[\306Mz\221-|\353\235?\200y\334R|\260\322\363U\236\237Im\025e\030\217\316\264=!\343\256o\024\346gm\232>\346\246\255\305\330*.!\211\215\277\316\370V\246R\273NNZ\235\032\215\342\320\200\330Q\211\344S^\210\201\027\036\306}\307\213\261\307\352\344\350\f+\332\344\003\354\0",
0x6C)= 108 0
close_nocancel(0x3)  = 0 0
issetugid(0x1, 0x7FFF5FBFFB45, 0x7FFF5FC40530)   = 0 0
geteuid(0x1, 0x7FFF5FBFFB45, 0x0)= 0 0
__sysctl(0x7FFF5FBFD760, 0x2, 0x7FFF5FBFD720)= 0 0
__sysctl(0x7FFF5FBFD720, 0x2, 0x7FFF5FBFD7BC)= 0 0
shared_region_check_np(0x7FFF5FBFD928, 0x0, 0x7FFF5FC1DC86)  = 0 0
stat64("/usr/lib/dtrace/libdtrace_dyld.dylib\0", 0x7FFF5FBFCD30,
0x7FFF5FBFD370 = 0 0
pread(0x3, "\312\376\272\276\0", 0x1000, 0x0)= 4096 0
pread(0x3, "\317\372\355\376\a\0", 0x1000, 0x1000)   = 4096 0
mmap(0x1000B6000, 0x2000, 0x5, 0x12, 0x3, 0x1)   = 0xB6000 0
mmap(0x1000B8000, 0x1000, 0x3, 0x12, 0x3, 0x1)   = 0xB8000 0
mmap(0x1000B9000, 0x1F10, 0x1, 0x12, 0x3, 0x1)   = 0xB9000 0
close(0x3)   = 0 0
stat64("/usr/lib/libncurses.5.4.dylib\0", 0x7FFF5FBFCAB0, 0x7FFF5FBFD0F0)   
 = 0 0
stat64("/usr/lib/libiconv.2.dylib\0", 0x7FFF5FBFCAB0, 0x7FFF5FBFD0F0)   
 = 0 0
stat64("/usr/lib/libSystem.B.dylib\0", 0x7FFF5FBFCAB0, 0x7FFF5FBFD0F0)  
 = 0 0
stat64("/usr/lib/system/libmathCommon.A.dylib\0", 0x7FFF5FBFC810,
0x7FFF5FBFCE50)  = 0 0
madvise(0x7FFF8961F000, 0x2000, 0x5) = 0 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF5FC45338) = 3 0
ioctl(0x3, 0x80086804, 0x7FFF5FBFD6C0)   = 0 0
close(0x3)   = 0 0
stat64("/usr/lib/libstdc++.6.dylib\0", 0x7FFF5FBFCAD0, 0x7FFF5FBFD110)  
 = 0 0
open("/dev/dtracehelper\0", 0x2, 0x7FFF5FC45400) = 3 0
ioctl(0x3, 0x80086804, 0x7FFF5FBFD6C0)   = 0 0
close(0x3)   = 0 0
__sysctl(0x7FFF5FBFD5B0, 0x2, 0x7FFF5FBFD5A0)= 0 0
bsdthread_register(0x7FFF837BC3DC, 0x7FFF8379CFF8, 0x2000)   = 0 0
sigprocmask(0x1, 0x0, 0x7FFF5FBFF8A0)= 0x0 0
sigaltstack(0x0, 0x7FFF5FBFF890, 0x0)= 0 0
open("/dev/tty\0", 0x6, 0x1) = 3 0
close(0x3)   = 0 0
getrlimit(0x1008, 0x7FFF5FBFF220, 0x7FFF8378684C)= 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_COLLATE\0", 0x0, 0x1B6) 
 = 3 0
fstat64(0x3, 0x7FFF5FBFF1F0, 0x7FFF5FBFF2BC) = 0 0
mmap(0x0, 0x100, 0x3, 0x1002, 0x200, 0x0)= 0x40 0
munmap(0x10040, 0x40)= 0 0
munmap(0x10100, 0x40)= 0 0
read_nocancel(0x3, "1.1A\n\0", 0x1000)   = 2086 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_CTYPE\0", 0x0, 0x1B6)   
 = 3 0
fstat64(0x3, 0x7FFF5FBFF2D0, 0x0)= 0 0
fstat64(0x3, 0x7FFF5FBFF0B0, 0x7FFF5FBFF17C) = 0 0
lseek(0x3, 0x0, 0x1) = 0 0
lseek(0x3, 0x0, 0x0) = 0 0
read_nocancel(0x3, "RuneMagAUTF-8\0", 0x1000)= 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "\0", 0x1000) = 4096 0
read_nocancel(0x3, "@\004\211\0", 0xDB70)= 56176 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_MONETARY\0", 0x0,
0x7FFF5FBFF39A)  = 3 0
fstat64(0x3, 0x7FFF5FBFF2E0, 0x0)= 0 0
read_nocancel(0x3, "USD
\n$\n.\n,\n3;3\n\n-\n2\n2\n1\n0\n1\n0\n1\n1\n\b\0", 0x22)= 34 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_NUMERIC\0", 0x0,
0x7FFF5FBFF3A9 = 3 0
fstat64(0x3, 0x7FFF5FBFF2F0, 0x0)= 0 0
read_nocancel(0x3, ".\n,\n3;3\n@$\b\0", 0x8) = 8 0
close_nocancel(0x3)  = 0 0
open_nocancel("/usr/share/locale/en_US.UTF-8/LC_TIME\0", 0x0,
0x7FFF5FBFF3A6)  = 3 0
fstat64(0x3, 0x

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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 and third times.

Would that be an SO_REUSEADDR-related issue?

Musing,

Andy
-- 
http://wingolog.org/

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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 delay in replying. I got the output of dtruss easily
> enough, but I don't know how to interpret it, and a lot of it seems to
> be noise from initialization.

I think that's just tracing the shell wrapper; use meta/uninstalled-env
libtool --mode=execute dtruss guile to get a more proper trace.

Anyway, what if you set the SO_REUSEADDR option?

Andy
-- 
http://wingolog.org/

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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 it
still happened.

Noah

On Sat, Feb 12, 2011 at 3:59 PM, Andy Wingo  wrote:
> 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 and third times.
>
> Would that be an SO_REUSEADDR-related issue?
>
> Musing,
>
> Andy
> --
> http://wingolog.org/
>

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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 its compiler
open("/Users/noah/Desktop/guile/guile/module/language/assembly/spec.go\0",
0x0, 0x0)= 54 0
fstat64(0x36, 0x7FFF5FBFEC00, 0x7FFF70825630)= 0 0
mmap(0x0, 0x3D2, 0x1, 0x1, 0x36, 0x10001)= 0xFE 0
stat64("/Users/noah/Desktop/guile/guile/module/language/assembly/decompile-bytecode.scm\0",
0x7FFF5FBFEA30, 0x10070A11B) = 0 0
mmap(0x0, 0x19F, 0x1, 0x1, 0x1C, 0x1)= 0x1F11000 0

;; At this point it's running the script
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 descriptor 49. result 2 probably means it is read and writable.
lseek(0x49, 0x0, 0x1)= -1 Err#29 ; errno 29 is "illegal 
seek"
setsockopt(0x49, 0x, 0x4)= 0 0  ; setsockopt on descriptor 
49
bind(0x49, 0x100709EE0, 0x10)= -1 Err#49  ; bind descriptor 49.
errno 49 is "protocol driver not attached"

;; And now there's already been an error, and we'll backtrace it.
write(0x2, "Backtrace:\n\0", 0xB)= 11 0
...

It seems to me that the strangest issue is that socket() return file
descriptor 73, but the script then did system calls on file descriptor
49. Does anyone know a reason that would happen?

Noah

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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 descriptor 49. result 2 probably means it is read and writable.
> lseek(0x49, 0x0, 0x1)  = -1 Err#29 ; errno 29 is "illegal 
> seek"
> setsockopt(0x49, 0x, 0x4)  = 0 0  ; setsockopt on descriptor 
> 49
> bind(0x49, 0x100709EE0, 0x10)  = -1 Err#49  ; bind descriptor 49.
> errno 49 is "protocol driver not attached"
>
> ;; And now there's already been an error, and we'll backtrace it.
> write(0x2, "Backtrace:\n\0", 0xB)  = 11 0
> ...
>
> It seems to me that the strangest issue is that socket() return file
> descriptor 73, but the script then did system calls on file descriptor
> 49. Does anyone know a reason that would happen?

#x49 is 73 :)

Could the lseek could be the problem?

A
-- 
http://wingolog.org/

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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. So that's what's happening
there.

However, I looked to see where the lseek call was coming from, and it
happens in scm_fdes_to_port, on line 564 of fports.c. The lseek is
done for the purpose of checking whether the port supports lseek, and
when it returns -1, we put an entry into some data structure (port
table?) saying that it doesn't support random access. So it looks like
that error is actually expected in the port code.

Noah

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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
contain its length, but in fact contained junk. Second of all, it
should have been padded with 8 bytes of zeros at the end, but it
wasn't. After experimenting a bit, it turns out that padding with
zeros was what made the difference, but probably the sa_len field
should be fixed anyway. I'll work on a patch for this.

Noah

On Sat, Feb 12, 2011 at 8:22 PM, Noah Lavine  wrote:
> 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. So that's what's happening
> there.
>
> However, I looked to see where the lseek call was coming from, and it
> happens in scm_fdes_to_port, on line 564 of fports.c. The lseek is
> done for the purpose of checking whether the port supports lseek, and
> when it returns -1, we put an entry into some data structure (port
> table?) saying that it doesn't support random access. So it looks like
> that error is actually expected in the port code.
>
> Noah
>

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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
> 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
> contain its length, but in fact contained junk. Second of all, it
> should have been padded with 8 bytes of zeros at the end, but it
> wasn't. After experimenting a bit, it turns out that padding with
> zeros was what made the difference, but probably the sa_len field
> should be fixed anyway. I'll work on a patch for this.
>
> Noah
>
> On Sat, Feb 12, 2011 at 8:22 PM, Noah Lavine  wrote:
>> 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. So that's what's happening
>> there.
>>
>> However, I looked to see where the lseek call was coming from, and it
>> happens in scm_fdes_to_port, on line 564 of fports.c. The lseek is
>> done for the purpose of checking whether the port supports lseek, and
>> when it returns -1, we put an entry into some data structure (port
>> table?) saying that it doesn't support random access. So it looks like
>> that error is actually expected in the port code.
>>
>> Noah
>>
>


0001-libguile-socket.c-fix-use-of-uninitialized-memory.patch
Description: Binary data

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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 PM, Noah Lavine  wrote:
> 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
>> 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
>> contain its length, but in fact contained junk. Second of all, it
>> should have been padded with 8 bytes of zeros at the end, but it
>> wasn't. After experimenting a bit, it turns out that padding with
>> zeros was what made the difference, but probably the sa_len field
>> should be fixed anyway. I'll work on a patch for this.
>>
>> Noah
>>
>> On Sat, Feb 12, 2011 at 8:22 PM, Noah Lavine  wrote:
>>> 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. So that's what's happening
>>> there.
>>>
>>> However, I looked to see where the lseek call was coming from, and it
>>> happens in scm_fdes_to_port, on line 564 of fports.c. The lseek is
>>> done for the purpose of checking whether the port supports lseek, and
>>> when it returns -1, we put an entry into some data structure (port
>>> table?) saying that it doesn't support random access. So it looks like
>>> that error is actually expected in the port code.
>>>
>>> Noah
>>>
>>
>


0001-configure.ac-sometimes-the-sin_len-member-appears-in.patch
Description: Binary data

Re: Bug in Guile's Posix Networking

[Ken Raeburn]

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 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.)

At first glance, the IPv6 flavor of the code looks okay on this score...

Ken

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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_
> sockaddr_in6     -> sin6_
> sockaddr_storage -> ss_
>
> 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.)

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. 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 would affect probably 10 or fewer
lines of code no matter what.

Noah

Re: Bug in Guile's Posix Networking

[Noah Lavine]

>> 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 this - the current code already contains a
test for a sockaddr.sin_len field. I don't know why it's there, but I
assumed that it was needed on some platform at some point. I left it
there, but added a check for sockaddr_in.sin_len as well.

Noah

Re: Bug in Guile's Posix Networking

[Ken Raeburn]

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 abbreviation for the struct type.  So sockaddr_in uses 
sin_ and not sa_.

If this were a pure C++ API we'd have inheritance and could just specify a 
length field in the base class "sockaddr" from which the others might be 
derived.  But for this ancient C/UNIX API, we have different structures with 
different field names, and must cast the pointers.

> 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 would affect probably 10 or fewer
> lines of code no matter what.

Yes, that's fine; just ditch the test for sockaddr (no _in) having a sin_len 
field.

Ken

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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, and
give the commit a good summary line.  See the patch that was pushed to
the repo for an example.

Thanks,

Andy
-- 
http://wingolog.org/

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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 would affect probably 10 or fewer
>> lines of code no matter what.
>
> Yes, that's fine; just ditch the test for sockaddr (no _in) having a sin_len 
> field.

Yes, I think this is the thing to do.

Can you rework your patch, Noah?

Thanks,

Andy
-- 
http://wingolog.org/

Re: Bug in Guile's Posix Networking

[Noah Lavine]

> Yes, I think this is the thing to do.
>
> Can you rework your patch, Noah?

Will do.

Re: Bug in Guile's Posix Networking

[Noah Lavine]

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

Re: Bug in Guile's Posix Networking

[Andy Wingo]

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/