Dag Brattli wrote:
>
> Itai Nahshon <[EMAIL PROTECTED]> writes:
>
> > Just to point to a (minor) bug implementation...
> >
> > The optlen parameter is both input and output. Getsockopts
> > should not copy out more than what the calling application
> > has requested. Until fixed, applications calling getsockopts
> > should just have a buffer that is large enough to contain the
> > maximal reply size.
>
> Thanks for pointing this out! I'll fix it! One other thing is that the
> device list is declared as an array of lenght 0. That is an ANSI C
> violation. I'll have to fix that as well. I'll try to make the IrDA socket
> interface as close to the IrDA WinSock as possible (until I find a much
> better way ;-)
>
> -- Dag
>
> > The hard coded limit of 10 discovered devices
> > may also be a problem (for very rare cases?).
>
> Yes, maybe 256 should be enough?
Is there a limit defined by IrDA (or other internal kernel hard limit)?
I haven't gotten that far in my reading.
256 entries would probably be too much to put on the syscall stack anyway.
Just get the list and copy_to_user one at a time until the size limit is
reached. The count can be the full value, so apps that want to get the whole
list can allocate a new buffer and call the function again. Note: it requires
some lock on the discovery list because writing to user space may sleep.
The nearest example that I know of in Linux is the implementation of
ioctl SIOCGIFCONF (see dev_ifconf in linux/net/core/dev.c).
Anyway, I tagged this as a minor bug... Chances of someone hitting this are
small and I'm sure there are higher priority items on your todo list.
>
> -- Dag
Itai
--
Itai Nahshon [EMAIL PROTECTED]
Also [EMAIL PROTECTED]
_______________________________________________
Linux-IrDA mailing list - [EMAIL PROTECTED]
http://www.pasta.cs.UiT.No/mailman/listinfo/linux-irda
