Well on iSeries the C compiler is very strict about these kind of typecast so the socklen_t should be used (and the build works with it).
If you're using JK_SOCKLEN_T via configure, since the iSeries didn't use it, please define it with #ifdef AS400 to 'link' it to socklen_t. 2006/7/18, Jean-frederic Clere <[EMAIL PROTECTED]>:
Rainer Jung wrote: > Mladen Turk wrote: > >> Anyhow, I suppose it should be neither int nor unsigned int, >> but rather size_t, at least that's the retval from sizeof, right? >> Of course its used by getsockopt that OTOH requires socklen_t. > > > Since it's only use is putting it into getsockopt(), I would suggest > the use of socklen_t and explicitely cast the return from sizeof(). I would suggest to have a JK_SOCKLEN_T as we have the JK_INT*, just in case a platform does not have socklen_t. (See configure.in) Cheers Jean-Frederic > >> I just wonder who is the genius that invented something that >> stupid as socklen_t :) >> I suppose it should be some sort of a size, correct? > > > Found some interesting pieces: > > 1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html > > Says: > > <sys/socket.h> makes available a type, socklen_t, which is an unsigned > opaque integral type of length of at least 32 bits. To forestall > portability problems, it is recommended that applications should not > use values larger than 2^32 - 1. > > 2) http://www.opengroup.org/austin/docs/austin_76r1.txt > > has interesting comments (...The type socklen_t is an unfortunate > historical accident...): > > The type socklen_t was invented to cover the range of implementations > seen in the field. The intent of socklen_t is to be the type for all > lengths that are naturally bounded in size, that is, that they are the > length of a buffer which cannot sensibly become of massive size: network > addresses, hostnames, string representations of these, ancillary data, > control messages, and socket options are examples. Truly boundless > sizes are represented by size_t as in read(), write(), etc. > > All socklen_t types were originally (in BSD UNIX) of type int. > During the development of the document it was decided to change > all buffer lengths to size_t, which appears at face value to make sense. > When dual mode 32/64 bit systems came along, this choice unnecessarily > complicated system interfaces because size_t (with long) was a different > size under ILP32 and LP64 models. Reverting to int would have happened > except that some systems had already shipped 64-bit only interfaces. The > compromise was a type which could be defined to be any size by the > implementation: socklen_t. > > and > > > People are continually confused about socklen_t. > > The type socklen_t is an unfortunate historical accident, and needed to > be invented to cover the range of implementations seen in the field. > The intent of socklen_t is to be the type for all lengths that are > naturally bounded in size, that is, that they are the length of a > buffer which cannot sensibly become of massive size: network addresses, > hostnames, string representations of these, ancillary data, control > messages, and socket options are examples. Truly boundless sizes are > represented by size_t as in read(), write(), etc. > > All socklen_t types were originally (in BSD UNIX) of type int. > An overzealous unknown decided without significant review to "correct" > all buffer lengths to size_t, which appears on its face to make sense. > When dual mode 32/64 bit systems came along, this choice unnecessarily > complicated system interfaces because size_t (with long) was a different > size under ILP32 and LP64 models. Reverting to int would have happened > except that some systems had already shipped 64-bit only interfaces. The > compromise was a type which could be defined to be any size by the > implementation: socklen_t. > > Rainer > >> >> -- >> Mladen. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
