On Mar 1, 2012, at 9:34 PM, William Herrin wrote:
> On Thu, Mar 1, 2012 at 8:47 PM, Owen DeLong <o...@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 <o...@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
