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]
