stdio in smbd

[Andy Polyakov]

> >       Ok folks, can we get this diagnosis
> >       verified and checked in, then?
> 
> It's not the right fix.

As already mentioned it wasn't a fix, but a sentence, a figure of speech
if you like...

> The right fix is to replace stdio with
> something that can handle more than 255 open files. That's why I added
> lib/xfile.c in Samba 3.0. It's a stripped down stdio replacement that
> doesn't have this problem.

Now imagine that some vendor or 3rd party library linked with smbd calls
stdio without you knowing that... Problem is back! Yes, it's possible to
arrange things so that those libraries will be linked with your routines
instead of stdio from libc... Now recall that some of stdio routines are
actually macros, most notably fileno (at least on Solaris 2.6), feof and
ferror... This means that if you're playing the linker trick on vendor
or 3rd party library, then your FILE structure should be binary
compatible with vendor stdio... It isn't (and can't be if you wish to
exend file descriptor structure member:-() and so the problem is back
again!

It should be noted that situation with 64-bit Solaris apps is completely
different. FILE structure is not exposed to applications at all and
therefore there're no macros.

> We also should switch to poll() from select() on systems that have
> it.

I would say switch to poll(2) only on systems that don't have select(2).
I mean it's a waste to scan through select's fds to fill up poll's fds
and then back whenever you can just pass it on to kernel.

> The select() interface is just broken,

Yet, front-end to poll has disappeared in 2.0.7.

A.