socket length arg fix (SAMBA_2_0 branch)

[Tim Rice]

On Mon, 14 Dec 1998, Jeremy Allison wrote:

> Tim Rice wrote:
> > 
> > On Mon, 14 Dec 1998, Andrej Borsenkow wrote:
> > 
> > >
> > > >
> > > > This patch uses socklen_t which by default is typedefed int so this
> > > > patch will NOT break any other systems.
> > >
> > > typedef'd int != int != size_t You create exactly the same problem you try
> > > to solve (size_t most probably is already typedef'd to int). You have to
> > > #define it
> > 
> > On UnixWare size_t is thpedef'd uint_t which is typedef'd unsigned int.
> > No, int != size_t.
> > And socket length args are != int on some platforms.
> > 
> > This is the way we solve the differences in the HylaFAX package.
> > I works fine.
> > 
> 
> The problem, even with your patch, is that there is no
> portable way to discover what prototype a particular
> system is using for the last argument to accept() etc.
> 
> Some (modern) systems use socklen_t * (the new standard),
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Thank you, Now I see the problem.
I didn't know socklen_t was part of a new standard.
We could easily pick some other name that no system uses.
Let's pick a new name and I'll redo the patch.

You are right, there is is no portable way to discover what prototype
a particular system is using for the last argument to accept() etc.
That's why it's a configure time option.
And for systems we know about, the case $target section.

> some use int *, some use unsigned int *.
> 
> We can check for socklen_t and use it if available,
> but if not then whichever we pick (int or unsigned int)
> is going to give compiler warnings on some systems.

You are using int now, that's why my patch defaults to int.

Again, the systems that get the warnings have the option of running
configure --with-CONFIG_SOCKARGLENTYPE=whatever_is_corect_for_their_system

> 
> Your patch helps, but I don't see it fixing it completely,
> and (IMHO) it's still a bit of a storm in a teacup as
> it's a compiler *warning* anyway. Stuff like the HPUX

My theory is fix all the easy warnings so when you get warnings you
will actually look at them instead of innoring them because you always
get warnings.

I get a clean compile on UnixWare 7 with this patch.

> compiler error messages and the AIX getrlimit bugs are
> more important anyway. I don't want us to get *too*
> obsessed with the details - there is still plenty 
> of actual *coding* to be done :-) :-).
> 
> Cheers,
> 
> 	Jeremy.
> 
> 

-- 
Tim Rice			Multitalents	(707) 887-1469 (voice)
tim at trr.metro.net