tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-frederic Clere <jfcl...@gmail.com>
Subject Re: Next try: mod_jk 1.2.17 release candidate ready to test
Date Tue, 18 Jul 2006 07:20:23 GMT
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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message