Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
RE: [Breakage] curl 8.9.0 tool_operate.c introduces use of ss_family
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Randall via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 24 Jul 2024 11:29:49 -0400
>-----Original Message-----
>From: rsbecker_at_nexbridge.com <rsbecker_at_nexbridge.com>
>Sent: Wednesday, July 24, 2024 10:50 AM
>To: rsbecker_at_nexbridge.com; 'libcurl development'
<curl-library_at_lists.haxx.se>
>Subject: RE: [Breakage] curl 8.9.0 tool_operate.c introduces use of
ss_family
>
>On Wednesday, July 24, 2024 10:47 AM, I wrote:
>>The introduction of the use of ss_family is not necessarily portable
>>and
>causes
>>breakages on NonStop (among others). What is the best way to suppress,
>>get
>past,
>>this? Undefining IP_TOS is not an option as this is defined by the
>operating system.
>>I have sun_family, but not ss_family.
>
>Actually, I have __ss_family and will go with that for now. I think that is
what is
>meant.
For discussion: my suggestion for this situation is as follows (roughly). I
am not sure how broadly this issue presents, so went flexible in the first
option.
#ifdef IP_TOS
static int get_address_family(curl_socket_t sockfd)
{
struct sockaddr_storage addr;
socklen_t addrlen = sizeof(addr);
if(getsockname(sockfd, (struct sockaddr *)&addr, &addrlen) == 0)
# if defined SS_FAMILY_NORMAL
return addr.ss_family;
# elif defined SS_FAMILY_PREFACED
return addr.__ss_family;
# else
return AF_UNSPEC;
# endif
return AF_UNSPEC;
}
#endif
Alteratively, we can go with predefines (NonStop = __TANDEM). We could add
__GNUC__ as a separate case.
#ifdef IP_TOS
static int get_address_family(curl_socket_t sockfd)
{
struct sockaddr_storage addr;
socklen_t addrlen = sizeof(addr);
if(getsockname(sockfd, (struct sockaddr *)&addr, &addrlen) == 0)
# ifdef __TANDEM
return addr.__ss_family;
# else
return addr.ss_family;
# endif
return AF_UNSPEC;
}
#endif
I can make a formal PR if requested.
Regards,
Randall
Date: Wed, 24 Jul 2024 11:29:49 -0400
>-----Original Message-----
>From: rsbecker_at_nexbridge.com <rsbecker_at_nexbridge.com>
>Sent: Wednesday, July 24, 2024 10:50 AM
>To: rsbecker_at_nexbridge.com; 'libcurl development'
<curl-library_at_lists.haxx.se>
>Subject: RE: [Breakage] curl 8.9.0 tool_operate.c introduces use of
ss_family
>
>On Wednesday, July 24, 2024 10:47 AM, I wrote:
>>The introduction of the use of ss_family is not necessarily portable
>>and
>causes
>>breakages on NonStop (among others). What is the best way to suppress,
>>get
>past,
>>this? Undefining IP_TOS is not an option as this is defined by the
>operating system.
>>I have sun_family, but not ss_family.
>
>Actually, I have __ss_family and will go with that for now. I think that is
what is
>meant.
For discussion: my suggestion for this situation is as follows (roughly). I
am not sure how broadly this issue presents, so went flexible in the first
option.
#ifdef IP_TOS
static int get_address_family(curl_socket_t sockfd)
{
struct sockaddr_storage addr;
socklen_t addrlen = sizeof(addr);
if(getsockname(sockfd, (struct sockaddr *)&addr, &addrlen) == 0)
# if defined SS_FAMILY_NORMAL
return addr.ss_family;
# elif defined SS_FAMILY_PREFACED
return addr.__ss_family;
# else
return AF_UNSPEC;
# endif
return AF_UNSPEC;
}
#endif
Alteratively, we can go with predefines (NonStop = __TANDEM). We could add
__GNUC__ as a separate case.
#ifdef IP_TOS
static int get_address_family(curl_socket_t sockfd)
{
struct sockaddr_storage addr;
socklen_t addrlen = sizeof(addr);
if(getsockname(sockfd, (struct sockaddr *)&addr, &addrlen) == 0)
# ifdef __TANDEM
return addr.__ss_family;
# else
return addr.ss_family;
# endif
return AF_UNSPEC;
}
#endif
I can make a formal PR if requested.
Regards,
Randall
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-07-24