On Fri, 2011-07-29 at 22:23 +0200, Corinna Vinschen wrote: > On Jul 29 13:30, Eric Blake wrote: > > Is there any specific reason why socklen_t on cygwin is int instead > > of uint32_t, like it is on Linux? > > Other than history? No, I don't think so. But I also don't think > it's worth the effort. All the underlying Windows functions typically > use int rather than uint32_t, and even the Linux man page states: > > The optlen argument of getsockopt() and setsockopt() is in reality an > int [*] (and this is what 4.x BSD and libc4 and libc5 have). Some > POSIX confusion resulted in the present socklen_t, also used by glibc.
FWIW, I am aware of the following packages which are affected by the difference: kdebase-runtime libgcrypt libunique But POSIX says[1]: > The <sys/socket.h> header shall define the socklen_t type, which is an > integer type of width of at least 32 bits... > > To forestall portability problems, it is recommended that applications > not use values larger than 2^31 -1 for the socklen_t type. That would seem to allow either 'uint32_t' or 'int', so we're not wrong, and its the aforementioned applications' fault for making Linux assumptions. Yaakov [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
