On Wed, 2006-01-25 at 10:42 -0800, Juan Lang wrote:
Although I don't like the idea of predefined limits :) I'll probably
Me neither, which is why I used that prominent macro MOST_INTERFACES_IMAGINABLE. Can you even imagine a system with 50 (or 100?) ethernet interfaces? How about an application that needs more than 256K (showing my age with that one... %)?
Yes, you're right, it is changeable, but it's less the number of interfaces than the value of the indexes. The interface implies that there will never be an interface with index 0, since if_nametoindex returns 0 to indicate no such interface, but what's to prevent interface indexes to be something other than 1, 2, 3, 4? They don't happen to be at the moment, but if some enterprising kernel guy decides to randomize them for some cute reason, this approach won't work.
Agreed. I can't find any docs explaining what indexes are legal or their order. I guess the reality is that it isn't specified.
The function does seem to be provided by libc. And so the diff must be in the implementations of that. Is there any precedent in Wine of making a runtime decision based on the c library? Would you be OK with a patch that uses if_indextoname() only in the special case of glibc-2.2.93 (I believe that's the RH8 libc), but if_nameindex() otherwise?
- mo