[gpm] socklen_t handling

[Enrico Weigelt]

* Nico Schottelius <nico-gpm@schottelius.org> wrote:

> Mike Frysinger [Sat, May 31, 2008 at 12:23:20AM -0400]:
> > is there a reason the usage of socklen_t in gpm is inconsistent ?
> 
> "it's all about history..."

As so many things in gpm ;-P

> > if the code 
> > base you're building against doesnt supply socklen_t, it's a great big pile 
> > imo (this is after all required by POSIX).  if we want to support such crappy 
> > systems, we should move the socklen_t check into configure and have the 
> > source assume it's available.
> 
> I think that's a good solution (autoconf/assume it is there/exit 
> error if not).

I don't think we even should care at all. IMHO, the (BSD) socket 
interface includes socklen_t. So either this interface is completely! 
there, or not at all. In longer terms, it makes no sense maintaining 
hacks for individual broken systems. *If* someone really comes around 
a system which has sockets but no socklen_t, it's simply broken (just 
my rude definition ;-P) and he should fix it. And if he can't fix the 
system itself, he should use an proper cross-toolchain. 

One general note: interfaces are like contracts. Once you signed a 
contract (=say that you provide certain interface), you MUST fulfil
that contract or cancel it. Simply breaking an valid contract is 
a very very bad thing. In our gilde, this essentially is called 
"design by contract" ;-p


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------