tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Gomez" <henri.go...@gmail.com>
Subject Re: Next try: mod_jk 1.2.17 release candidate ready to test
Date Tue, 18 Jul 2006 07:52:12 GMT
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 <jfclere@gmail.com>:
> 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
>
>

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


Mime
View raw message