On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong <owen@delong.com> wrote:
On Mar 1, 2012, at 5:15 PM, William Herrin wrote:
On Thu, Mar 1, 2012 at 8:02 PM, Owen DeLong <owen@delong.com> wrote:
There's no need to break the current functionality of the underlying system calls and libc functions which would be needed by any such library anyway.
Owen,
Point to one sentence written by anybody in this entire thread in which breaking current functionality was proposed.
When you said that:
connect(char *name, uint16_t port) should work
That can't work without breaking the existing functionality of the connect() system call.
You know, when I wrote 'socket=connect("www.google.com",80,TCP);' I stopped and thought to myself, "I wonder if I should change that to 'connectbyname' instead just to make it clear that I'm not replacing the existing connect() call?" But then I thought, "No, there's a thousand ways someone determined to misunderstand what I'm saying will find to misunderstand it. To someone who wants to understand my point, this is crystal clear."
I'm all for additional library functionality built on top of what exists that does what you want. As I said, there are many such libraries out there to do that. If someone wants to add it to libc, more power to them. I'm not the libc maintainer. I just don't want conect() to stop working the way it does or for getaddrinfo() to stop working the way it does. Since you were hell bent on calling the existing mechanisms broken rather than conceding the point that the current process is not broken, but, could stand some improvements in the library (http://owend.corp.he.net/ipv6 I even say as much myself), it was not entirely clear that you did not intend to replace connect() rather than augment the current capabilities with additional more abstract functions with different names. Owen