* Nico Schottelius <nico-gpm@xxxxxxxxxxxxxxx> 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/ --------------------------------------------------------------------- _______________________________________________ gpm mailing list gpm@xxxxxxxxxxxxxx http://lists.linux.it/listinfo/gpm