On 09/06/2026 20:41, Christopher Schultz wrote:
Mark,
On 6/9/26 11:24 AM, Mark Thomas wrote:
On 08/06/2026 18:17, Christopher Schultz wrote:
Rainer,
On 6/8/26 12:58 PM, Rainer Jung wrote:
Am 08.06.26 um 18:06 schrieb Christopher Schultz:
All,
Is the sockaddr_storage data type available on all the platforms we
support for mod_jk?
I'm not even sure what the best way to find that out is. It's
supposed to be a POSIX standard, but maybe we don't even require
POSIX.
@Rainer, you have access to some more varied environments than I
do. Can you tell me if using sockaddr_storage is going to be safe?
It seems available on my linux systems (starting with RHEL 7 and
SLES 12, don't know about older ones) and Solaris 10 Sparc.
It seems we currently detect presence in configure and native/
common/ jk_global.h uses it if it is available.
What are your intentions?
struct sockaddr isn't big enough to fit IPv6 data, and we pretend
like it is.
$ cat sock_info.c
#include <sys/socket.h>
#include <netinet/in.h>
#include <stdio.h>
int main(int argc, char *argv[], char *env[]) {
printf("sizeof(struct sockaddr) = %lu\n", sizeof(struct sockaddr));
printf("sizeof(struct sockaddr_in) = %lu\n", sizeof(struct
sockaddr_in));
printf("sizeof(struct sockaddr_in6) = %lu\n", sizeof(struct
sockaddr_in6));
printf("sizeof(struct sockaddr_storage) = %lu\n", sizeof(struct
sockaddr_storage));
return 0;
}
$ cc -o sock_info sock_info.c && ./sock_info
sizeof(struct sockaddr) = 16
sizeof(struct sockaddr_in) = 16
sizeof(struct sockaddr_in6) = 28
sizeof(struct sockaddr_storage) = 128
This is consistent on my x86-64 Linux server, my arm64 MacOS laptop,
and an arm64-based Linux server.
We have code in mod_jk that allocates a "struct sockaddr" and then
calls getsockname and getpeername with what is likely to be an
undersized buffer. I think it's safe (due to its usage) but I think
it will fail for IPv6 environments. This is in jk_dump_sinfo.
I have a patch ready to go, but I wanted to check to see if it's okay
to use.
Google tells me that we would need to add this to autoconf:
AC_CHECK_TYPE([struct sockaddr_storage], [], [
AC_MSG_ERROR([struct sockaddr_storage is required but not found])
], [
#include <sys/types.h>
#include <sys/socket.h>
])
But I don't know enough about autoconf to actually add that. :/
It would surely be better to add this to autoconf than to have the
build fail due to a missing data type, so I'm happy to add it. But I
don't want this to break someone downstream.
Another alternative would be to use APR (which is already a
requirement) but I wasn't looking for a complete re-factoring at this
point.
My code review flagged up that support for "struct sockaddr" was now a
requirement.
There was an existing test for "struct sockaddr". I have switched the
test to require "struct sockaddr" and updated the build to reflect the
changes. It builds for me and CoPilot thinks it is OK so there is a
reasonable chance I did the right thing.
Commit to follow shortly.
So we already required "struct sockaddr" whether it was advertised or
not. What we require now is "struct sockaddr_storage".
Sorry. I mis-typed.
There was a test for "struct sockaddr_storage" but the presence of
"struct sockaddr_storage" was optional. It is now required.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
