[Bug libc/9700] a means to sort addrinfo list

["stlman at poczta dot fm" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From stlman at poczta dot fm  2009-01-04 23:57 -------
(In reply to comment #3)

Please allow me to explain my point of view once again. Maybe I will manage to
do this clearly enough this time.

I *wish* (that's why I consider it a possible enhancement not a required bugfix)
there was a function in glibc that would take a list or an array of addrinfo
structures and sort it the same way as getaddrinfo() does. I think this is a
reasonable wish because the DNS (which is queried from within  getadrinfo()) is
not the only way to obtain network addresses which should be sorted before using
them. I considered enhancing getaddrinfo() because it already is a very
versatile function as it replaces gethostbyname() *and* inet_aton() (et al.).
Yet I do not really insist on enhancing getaddrinfo(), though this might need
less new code, but I also would agree on adding completely new function, the
sortaddrinfo() function. A function to sort a list of addresses not from the DNS
but from a different source.

Now please let me ask you few questions which might help us understand each other. 

1) Is the DNS the only way of obtaining network addresses?
2) Are there no application level network protocols which carry information
about network addresses applications want to connect to?
3) Does it make sense to write the same code someone already wrote?

If you answer "no" at least one of those then it means that glibc should provide
a function to sort a list of addrinfo structures created outside of the
getaddrinfo() function and containing addresses that may come even from a
crystal ball or a thin air. 

> Stop reopening.  

OK but I won't stop adding comments until you give a good reason not to either:

1) Create a new function sortaddrinfo() (a little bit more code but the API
would look better),

or

2) define AI_SORT hint flag and make getaddrinfo() accept it and:
a) do no DNS query
b) do not look at neither node nor service
c) do not allocate addrinfo list
d) sort the provided addrinfo list (it would be both "in" and "out") as if it
has been obdained from DNS.

>I have explained in detail why this proposal makes no sense at
> all.  

No you haven't. Most probably because I was not clear enough, my fault. Such
function is more or less required by every programme which connects remote hosts
and does not use the DNS to get their addresses. 

> You writing
> 
>    And why is that? If you assign an unused bit the new meaning doesn't break
>    anything?
> 
> makes it abundantly clear you didn't even thought the problem through.  It's
> irrelevant whether it can the implemented without breaking anything.
> No program will use this code out of the box.

Gee man! Are you serious or just trolling? No wonder it won't as it is
completely new thing. If there are any programmes that obtain addresses from
different sources than DNS they probably their authors have implemented sorting
themselves because they had to. Just like no one knew how to drive a car 200
years ago, did he? That's why I chose "enhancement".

> If you want to use it for anything then
> you'll have to modify the binaries you think need it yourself.

Now I am totally lost. Why should I modify binaries? Why not source? Maybe I
would like to modify some source that don't handle reasonably a list of more
than one address it connects to (e.g. PSI instant messenger). 

I want it for programmes that maybe even don't exist yet. Remember? The
"enhancement" thing?

> Then you can
> just as well implement it all yourself and re-sort the list.

Yeah sure I do nothing else but dreaming about how much I want to rewrite the
bloody gai.conf stuff and sorting and, in fact, at least a half of getaddrinfo.c?

The DNS is not the only way of getting addresses. All addresses should always be
sorted before using them. Do these sentences make sense?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9700

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.