Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Daniel Stenberg via curl-library]

On Wed, 21 Sep 2022, Daniel Stenberg via curl-library wrote:

Yes. It sounds like we should be able to fix this by "lazily" do the check 
first when it is actually necessary to know. If set to CURL_IPRESOLVE_V4 
there's no need to know.


Whatever we decide here, I think this is a good idea so I went ahead and made 
a pull-request with a change like this.


See https://github.com/curl/curl/pull/9553

--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Daniel Stenberg via curl-library]

On Tue, 20 Sep 2022, Dan Fandrich via curl-library wrote:

How doesn't setting CURLOPT_IPRESOLVE fix this? Is it because 
Curl_ipv6works() is being called somewhere anyway, and it adds a 30 msec 
delay? So, if libcurl eliminated that call in the CURL_IPRESOLVE_V4 case, 
would it fix your problem?


Yes. It sounds like we should be able to fix this by "lazily" do the check 
first when it is actually necessary to know. If set to CURL_IPRESOLVE_V4 
there's no need to know.


--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dan Fandrich via curl-library]

On Tue, Sep 20, 2022 at 11:49:08PM +, Dmitry Karpov via curl-library wrote:
> No matter how difficult it is (and maybe not always possible) to do it in 
> multiple places, setting IP_RESOLVE option doesn't solve the problem which I 
> am trying to resolve via this proposal.

How doesn't setting CURLOPT_IPRESOLVE fix this? Is it because Curl_ipv6works()
is being called somewhere anyway, and it adds a 30 msec delay? So, if libcurl
eliminated that call in the CURL_IPRESOLVE_V4 case, would it fix your problem?
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dmitry Karpov via curl-library]

No, it is not just an engineering issue, which can be solved by changing some 
easy handle settings in multiple places.
No matter how difficult it is (and maybe not always possible) to do it in 
multiple places, setting IP_RESOLVE option doesn't solve the problem which I am 
trying to resolve via this proposal.

The "IPv6 works" is checked when a multi handle is created, but before any easy 
handle is added to it, so it is not related to the IP_RESOLVE option set on any 
easy handle added to that multi handle later.
This is a "system setting" which is checked and set only once when a multi 
handle is created.

The "CURLOPT_USE_SSL, CURLOPT_FOLLOWLOCATION, CURLOPT_USERAGENT or tons of 
other options" are transfer-specific options managing what some specific 
transfer would like to use, whereas "IPv6 works" is a system setting, which 
essentially affects all handles used in the application.

So, currently even if IP_RESOLVE is set to IPV4_ONLY for some easy handle, any 
transfer including transfer doing "easy transfer" via curl_easy_perform() 
(which creates a multi handle under the hood) will step on this regression when 
using IPv6-enabled dual stack libcurl vs IPv4 single stack libcurl.

The default Curl_ipv6works() is a good default method to detect where IPv6 
works or not on the system, but as any default - it is not the best method for 
ALL possible scenarios.
That's why I see the need to provide additional flexibility allowing to detect 
whether IPv6 works or not in a better way than Curl_ipv6works() does.

And again, this issue occurs regardless which IP_RESOLVE setting is used on 
some easy handle.

Thanks,
Dmitry Karpov

-Original Message-
From: Dan Fandrich  
Sent: Tuesday, September 20, 2022 2:57 PM
To: Dmitry Karpov 
Subject: Re: [EXTERNAL] Re: Feature request: provide ability to set a global 
callback function telling libcurl if IPv6 works on the system

On Tue, Sep 20, 2022 at 09:23:35PM +, Dmitry Karpov wrote:
> That's exactly what I would like to avoid - going through a gazillion places 
> in numerous components and change something there just to improve how 
> Curl_ipv6works().

This argument could be made for a hundred other options. Other applications 
want to set CURLOPT_USE_SSL, CURLOPT_FOLLOWLOCATION, CURLOPT_USERAGENT or tons 
of other options on every handle, or CURLOPT_FTP_SKIP_PASV_IP, 
CURLOPT_TCP_KEEPALIVE or CURLOPT_DNS_LOCAL_IP6 based on local network 
conditions, but none of those make any sense to have set in a callback, either. 
It sounds to me like the underlying issue isn't really a technical one but 
rather a software engineering one, which patching libcurl isn't going to solve.

Dan
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dmitry Karpov via curl-library]

> I still haven't seen any reason this needs to be a callback, besides that 
> it's easier to integrate into your program.
> If you insist on this being a callback, then you can just call it yourself by 
> changing your code from using 
>  curl_easy_init() everywhere to using dmitry_curl_easy_init():

That's exactly what I would like to avoid - going through a gazillion places in 
numerous components and change something there just to improve how 
Curl_ipv6works().

Unfortunately, my "application" is a quite large - with a lot of independent 
components which are not easy or even feasible to change.
Some of the components using curl code are "3rd party" code integrated into my 
application, which I just can't change, and which also have regressions caused 
by default Curl_ipv6works() behavior.

So again, the "curl_global_init_ipv6() with callback" approach solves this 
problem very easily and cleanly with minimal changes in the code and without 
any need to touch "closed code" components, which just can't be modified.

Besides, Curl already has mechanism allowing applications to define global 
memory management functions. 
So, the "IPv6 works" callback will be just another application/system level 
callback allowing to tune how the application should handle some "system" level 
behavior.

Thanks,
Dmitry Karpov


-Original Message-
From: curl-library  On Behalf Of Dan 
Fandrich via curl-library
Sent: Tuesday, September 20, 2022 1:42 PM
To: libcurl development 
Cc: Dan Fandrich 
Subject: Re: [EXTERNAL] Re: Feature request: provide ability to set a global 
callback function telling libcurl if IPv6 works on the system

On Tue, Sep 20, 2022 at 08:28:10PM +, Dmitry Karpov wrote:
> Yes, I want to use dual-stack in general. That's why my application has 
> numerous components which use CURLOPT_IPRESOLVE = AUTO.
> But if IPv6 doesn't work on a "system level", I want my curl code to be as 
> fast as "IPv4 only" resolve mode without changing anything in my code - like 
> doing detection that IPv6 doesn't work and modifying IP resolve mode in all 
> the places where I create and set an easy handle (that's your suggestion as I 
> understood it).

I still haven't seen any reason this needs to be a callback, besides that it's 
easier to integrate into your program. If you insist on this being a callback, 
then you can just call it yourself by changing your code from using
curl_easy_init() everywhere to using dmitry_curl_easy_init():

CURL *dmitry_curl_easy_init(void) {
  CURL *c=curl_easy_init();
  my_ipv6_callback(c);
  return c;
}

libcurl doesn't need a new callback mechanism to do this.

Dan
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dan Fandrich via curl-library]

On Tue, Sep 20, 2022 at 08:28:10PM +, Dmitry Karpov wrote:
> Yes, I want to use dual-stack in general. That's why my application has 
> numerous components which use CURLOPT_IPRESOLVE = AUTO.
> But if IPv6 doesn't work on a "system level", I want my curl code to be as 
> fast as "IPv4 only" resolve mode without changing anything in my code - like 
> doing detection that IPv6 doesn't work and modifying IP resolve mode in all 
> the places where I create and set an easy handle (that's your suggestion as I 
> understood it).

I still haven't seen any reason this needs to be a callback, besides that it's
easier to integrate into your program. If you insist on this being a callback,
then you can just call it yourself by changing your code from using
curl_easy_init() everywhere to using dmitry_curl_easy_init():

CURL *dmitry_curl_easy_init(void) {
  CURL *c=curl_easy_init();
  my_ipv6_callback(c);
  return c;
}

libcurl doesn't need a new callback mechanism to do this.

Dan
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dmitry Karpov via curl-library]

> I don't see your argument. Either you want IPv6 for a connection or you don't.

Yes, I want to use dual-stack in general. That's why my application has 
numerous components which use CURLOPT_IPRESOLVE = AUTO.
But if IPv6 doesn't work on a "system level", I want my curl code to be as fast 
as "IPv4 only" resolve mode without changing anything in my code - like doing 
detection that IPv6 doesn't work and modifying IP resolve mode in all the 
places where I create and set an easy handle (that's your suggestion as I 
understood it).

In other words, I want benefits of dual-stack when it works, and I don't want 
to pay any performance penalties when it doesn't.
And I also don't want to pay code change penalties to modify CURLOPT_IPRESOLVE 
to IPv4 for cases when IPv6 doesn't work in ALL the places where easy handles 
are created and set up.

> . A callback is only useful if the application needs to change something 
> while a transfer is ongoing

The callback I am proposing is a global application callback, not a 
transfer-specific callback which, indeed, is needed only for 
transfer-in-progress operations.

My callback will be set when application initializes curl via 
curl_global_init_ipv6() function, and it will be used when a multi handle is 
created (and before any easy handles are added to it) to set "IPv6 works" mode 
for the multi-handle .

This is very similar to what Curl_ipv6works() currently does, only my proposal 
will allow to use application-specific function instead of Curl_ipv6works().

Thanks,
Dmitry  Karpov

-Original Message-
From: curl-library  On Behalf Of Dan 
Fandrich via curl-library
Sent: Tuesday, September 20, 2022 12:58 PM
To: libcurl development 
Cc: Dan Fandrich 
Subject: Re: [EXTERNAL] Re: Feature request: provide ability to set a global 
callback function telling libcurl if IPv6 works on the system

On Tue, Sep 20, 2022 at 07:24:42PM +, Dmitry Karpov wrote:
> Not necessarily. 
> If we have a bunch of applications on the system with large codebases which 
> use CURLOPT_IPRESOLVE = AUTO in too many places, then all these places should 
> detect somehow that "IPv6 doesn't work" and change the resolve mode to IPv4. 
> It is just not always feasible or desirable.
> 
> The "curl_global_init_ipv6() with callback" solves this problem very easily 
> and cleanly - as just one global callback can instantly tell all multi 
> handles created in the application that "IPv6 doesn't work" and let them all 
> fall back to IPv4.

I don't see your argument. Either you want IPv6 for a connection or you don't. 
Just set the right value using curl_easy_getopt() before you call perform. A 
callback is only useful if the application needs to change something while a 
transfer is ongoing, which isn't the case for this option.
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dan Fandrich via curl-library]

On Tue, Sep 20, 2022 at 07:24:42PM +, Dmitry Karpov wrote:
Not necessarily. 
If we have a bunch of applications on the system with large codebases which use CURLOPT_IPRESOLVE = AUTO in too many places, then all these places should detect somehow that "IPv6 doesn't work" and change the resolve mode to IPv4. It is just not always feasible or desirable.


The "curl_global_init_ipv6() with callback" solves this problem very easily and cleanly - 
as just one global callback can instantly tell all multi handles created in the application that 
"IPv6 doesn't work" and let them all fall back to IPv4.


I don't see your argument. Either you want IPv6 for a connection or you don't. 
Just set the right value using curl_easy_getopt() before you call perform. A 
callback is only useful if the application needs to change something while a 
transfer is ongoing, which isn't the case for this option.

--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dmitry Karpov via curl-library]

> An option like CURLOPT_IPRESOLVE seems like a much cleaner solution.

Not necessarily. 
If we have a bunch of applications on the system with large codebases which use 
CURLOPT_IPRESOLVE = AUTO in too many places, then all these places should 
detect somehow that "IPv6 doesn't work" and change the resolve mode to IPv4. It 
is just not always feasible or desirable.

The "curl_global_init_ipv6() with callback" solves this problem very easily and 
cleanly - as just one global callback can instantly tell all multi handles 
created in the application that "IPv6 doesn't work" and let them all fall back 
to IPv4.

Thanks,
Dmitry


-Original Message-
From: curl-library  On Behalf Of Dan 
Fandrich via curl-library
Sent: Tuesday, September 20, 2022 12:14 PM
To: curl-library@lists.haxx.se
Cc: Dan Fandrich 
Subject: [EXTERNAL] Re: Feature request: provide ability to set a global 
callback function telling libcurl if IPv6 works on the system

On Tue, Sep 20, 2022 at 06:58:31PM +, Dmitry Karpov via curl-library wrote:
> To cover such a range of cases, curl application needs a more flexible 
> approach for detection whether IPv6 works on the "system level".
> And I guess the "curl_global_init_ipv6() with callback" provides such 
> flexibility and allows to satisfy a wide range of application-specific needs.

Without discussing of the merits of such an idea, a callback function doesn't 
seem like the right way to configure this in libcurl. An option like 
CURLOPT_IPRESOLVE seems like a much cleaner solution.

Dan
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dan Fandrich via curl-library]

On Tue, Sep 20, 2022 at 06:58:31PM +, Dmitry Karpov via curl-library wrote:
> To cover such a range of cases, curl application needs a more flexible 
> approach for detection whether IPv6 works on the "system level".
> And I guess the "curl_global_init_ipv6() with callback" provides such 
> flexibility and allows to satisfy a wide range of application-specific needs.

Without discussing of the merits of such an idea, a callback function doesn't
seem like the right way to configure this in libcurl. An option like
CURLOPT_IPRESOLVE seems like a much cleaner solution.

Dan
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

RE: Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Dmitry Karpov via curl-library]

> Ah, ok then I was wrong.

Yes, I use the same application with IPv6-enabled libcurl on different Linux 
kernel versions (both with IPv6 enabled and disabled on kernel level) for 
different embedded devices and some of them  (pretty recent 4.x, actually) show 
IPv6 socket delay failures.

Some kernel configurations show delays if IPv6 is not enabled in the kernel and 
some if IPv6 is not set on the network interface.
These kernels come from SOC vendors, and I can't debug and modify them to make 
IPv6 socket calls fail more quickly.

> Another approach could then perhaps be to make curl deal with such failures 
> in a better/fallback way to avoid needing the dynamic "ipv6-works" flag ?

Not sure, if I understand how curl can deal better with such problems.

The "IPv6 works" check (if it returns "false") allows to avoid Happy Eyeballs 
timeout delays during dual-stack connection establishment for cases when IPv6 
doesn't work on a system level.
It disables dual-stack on the multi handle and all connections are established 
using IPv4 afterwards.

And the "system level" may cover a quite wide range of cases - IPv6 is disabled 
on kernel level, IPv6 address is disabled on network interface(s),  IPv6 
connectivity check failed and system disabled in some configuration parameters 
etc.

To cover such a range of cases, curl application needs a more flexible approach 
for detection whether IPv6 works on the "system level".
And I guess the "curl_global_init_ipv6() with callback" provides such 
flexibility and allows to satisfy a wide range of application-specific needs.

Thanks,
Dmitry Karpov


-Original Message-
From: curl-library  On Behalf Of Daniel 
Stenberg via curl-library
Sent: Tuesday, September 20, 2022 12:05 AM
To: Daniel F via curl-library 
Cc: Daniel Stenberg 
Subject: [EXTERNAL] Re: Feature request: provide ability to set a global 
callback function telling libcurl if IPv6 works on the system

On Tue, 20 Sep 2022, Daniel F via curl-library wrote:

> This is not true. Application can be built using curl with IPv6 
> enabled (e.g. using RedHat 8 base docker image), then executed on 
> another system/machine with IPv6 disabled. If I remember correctly, 
> attempt to create IPv6 socket failed with error.

Ah, ok then I was wrong.

Another approach could then perhaps be to make curl deal with such failures in 
a better/fallback way to avoid needing the dynamic "ipv6-works" flag ?

-- 

  / daniel.haxx.se
  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: C99

[bch via curl-library]

On Tue, Sep 20, 2022 at 08:06 Emil Engler via curl-library <
curl-library@lists.haxx.se> wrote:

> On Tue, Sep 20, 2022 at 11:24:37AM +0200, Daniel Stenberg via curl-library
> wrote:
> > I am not entirely convinced we want to go all-in and totally crazy on all
> > these fronts immediately, and I think having an idea what we want in
> terms
> > of code style is a good idea to have thought about before the flood gates
> > open.
>
> While I'm not against a switch to C99, I consider most of the features
> introduced by it, to put it mildly, useless.  Sure, some things of it
> are very useful and cannot be achieved by ease in C89, such as
>  and variadic macros, but most of the other features, such as
>  and snprintf(3) can be implemeneted in C89 fairly easy and
> given the fact that curl already does that, as it has its own boolean
> type and printf(3)-functions, it's questionable if we should truly favor
> them to the cost of a slightly worser portability.
>
> A thing we could also do, would be to use C89 with GNU C Extensions
> (GNU89), but only make use of the GNU Extensions, which are also part of
> the C99 standard,


C89 w long long apparently, and does compile cleanly (without warnings) on
C99, according to a dev I talked to. The biggest issue (or "a big" issue)
with that standard is (lack of) file locking, but that'd be curls C89 case
as well.

-bch

as they have a big intersection with each other.  With
> this approach, we can make use of certain C99 features without dropping
> portability for certain gcc versions.  If I remember correctly, SQLite
> does exactly this.
>
> --Emil
> --
> Unsubscribe: https://lists.haxx.se/listinfo/curl-library
> Etiquette:   https://curl.se/mail/etiquette.html
>
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: C99

[Emil Engler via curl-library]

On Tue, Sep 20, 2022 at 11:24:37AM +0200, Daniel Stenberg via curl-library 
wrote:
> I am not entirely convinced we want to go all-in and totally crazy on all
> these fronts immediately, and I think having an idea what we want in terms
> of code style is a good idea to have thought about before the flood gates
> open.

While I'm not against a switch to C99, I consider most of the features
introduced by it, to put it mildly, useless.  Sure, some things of it
are very useful and cannot be achieved by ease in C89, such as
 and variadic macros, but most of the other features, such as
 and snprintf(3) can be implemeneted in C89 fairly easy and
given the fact that curl already does that, as it has its own boolean
type and printf(3)-functions, it's questionable if we should truly favor
them to the cost of a slightly worser portability.

A thing we could also do, would be to use C89 with GNU C Extensions
(GNU89), but only make use of the GNU Extensions, which are also part of
the C99 standard, as they have a big intersection with each other.  With
this approach, we can make use of certain C99 features without dropping
portability for certain gcc versions.  If I remember correctly, SQLite
does exactly this.

--Emil
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: C99

[Daniel Stenberg via curl-library]

On Tue, 20 Sep 2022, Christoph M. Becker wrote:

In my opinion, it makes sense to rely on some of the newer language 
capabilities, but note that MSVC does not support all required language 
features of C99 (only C11 and C17 are supported by recent versions). This 
means in particular that variable length arrays are not supported (and 
likely never will).


Good points. Someone on twitter also highligted for me that "the list of C99 
features you listed isn't compatible with C++ (only an issue if people insist 
on compiling curl in C++ mode)".


Although I will admit I don't know which those incompatible features are. I 
try hard to forget my C++ =)


--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

RE: C99

[Marcel Raad via curl-library]

Hi,

> At the same time, if we accept C99 it will be hard to enforce restrictions 
> with compilers and checksrc certainly will not stop most of the things in 
> that 
> list (the //-comments perhaps being the single exception).
>
> Thoughts?

I like the idea and agree that would be the perfect time to switch. Especially 
the mixed declarations and code will make contributions much easier for us C++ 
developers without getting headaches trying to avoid compiler warnings from 
conditionally used code.

Speaking of compiler restrictions though, as Christoph already mentioned, 
Visual Studio implemented (almost) full C99 support very late, which might be 
an issue:
- the intersection between C90 and C++98, like C++ comments and mixed code and 
declarations, has been supported since basically forever
- Visual Studio 2005 (which also dropped support for targeting Windows versions 
before 98 / NT 4.0) added variadic macros and long long
- Visual Studio 2010 (which only supports Windows XP and later) added stdint.h
- Visual Studio 2013 and later implemented more features
- full support (minus the features that were made optional in C11) was finally 
implemented in VS 2019 Update 8 (which only supports Windows Vista and later)

So we might have to use the subset of C99 supported by a particular "old 
enough" Visual Studio version, maybe 2013. And we could at the same time remove 
support for older Windows versions from the code, maybe making Windows 2000 the 
minimum, which classic MinGW still defaults to.

Marcel
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: C99

[Christoph M. Becker via curl-library]

Hi!

On 20.09.2022 at 11:24, Daniel Stenberg via curl-library wrote:

> New mail thread to make this topic more visible. The idea of switching
> to C99 as the base level for curl code when we go version 8 (March 2023)
> is attractive to me. I figure compilers have had some time to get
> compliant and find widespread use by now!
>
> I added a PR just now to (primarly as a test) enforce C89 on the code
> when gcc is used, and it shows that we are already a bit sloppy in C89
> compliance in several areas of our code base:
> https://github.com/curl/curl/pull/9542
>
> But what does "going C99" mean for us? The C99 standard brought a whole
> busload of different new features to the language compared to C89, and
> some of them are:
>
>  — `//` comments
>  — `__func__` predefined identifer
>  — boolean type in ``
>  — designated struct initializers
>  — empty macro arguments
>  — extended integer types in `` and ``
>  — fexible array members (zero size arrays)
>  — inline functions
>  — integer constant type rules
>  — mixed declarations and code
>  — the `long long` type and library functions
>  — the `snprintf()` family of functions
>  — trailing comma allowed in enum declaration
>  — vararg macros
>  — variable-length arrays
>
> I am not entirely convinced we want to go all-in and totally crazy on
> all these fronts immediately, and I think having an idea what we want in
> terms of code style is a good idea to have thought about before the
> flood gates open.
>
> At the same time, if we accept C99 it will be hard to enforce
> restrictions with compilers and checksrc certainly will not stop most of
> the things in that list (the //-comments perhaps being the single
> exception).

In my opinion, it makes sense to rely on some of the newer language
capabilities, but note that MSVC does not support all required language
features of C99 (only C11 and C17 are supported by recent versions).
This means in particular that variable length arrays are not supported
(and likely never will).  More details are available at
.

--
Christoph M. Becker
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

C99

[Daniel Stenberg via curl-library]

Hello,

New mail thread to make this topic more visible. The idea of switching to C99 
as the base level for curl code when we go version 8 (March 2023) is 
attractive to me. I figure compilers have had some time to get compliant and 
find widespread use by now!


I added a PR just now to (primarly as a test) enforce C89 on the code when gcc 
is used, and it shows that we are already a bit sloppy in C89 compliance in 
several areas of our code base: https://github.com/curl/curl/pull/9542


But what does "going C99" mean for us? The C99 standard brought a whole 
busload of different new features to the language compared to C89, and some of 
them are:


 — `//` comments
 — `__func__` predefined identifer
 — boolean type in ``
 — designated struct initializers
 — empty macro arguments
 — extended integer types in `` and ``
 — fexible array members (zero size arrays)
 — inline functions
 — integer constant type rules
 — mixed declarations and code
 — the `long long` type and library functions
 — the `snprintf()` family of functions
 — trailing comma allowed in enum declaration
 — vararg macros
 — variable-length arrays

I am not entirely convinced we want to go all-in and totally crazy on all 
these fronts immediately, and I think having an idea what we want in terms of 
code style is a good idea to have thought about before the flood gates open.


At the same time, if we accept C99 it will be hard to enforce restrictions 
with compilers and checksrc certainly will not stop most of the things in that 
list (the //-comments perhaps being the single exception).


Thoughts?

--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Daniel Stenberg via curl-library]

On Tue, 20 Sep 2022, Daniel F via curl-library wrote:

This is not true. Application can be built using curl with IPv6 enabled 
(e.g. using RedHat 8 base docker image), then executed on another 
system/machine with IPv6 disabled. If I remember correctly, attempt to 
create IPv6 socket failed with error.


Ah, ok then I was wrong.

Another approach could then perhaps be to make curl deal with such failures in 
a better/fallback way to avoid needing the dynamic "ipv6-works" flag ?


--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system

[Daniel F via curl-library]

W dniu 2022-09-20 08:22, Daniel Stenberg via curl-library napisał(a):

On Mon, 19 Sep 2022, Dmitry Karpov via curl-library wrote:

Working with IPv6-enabled dual-stack libcurl, I noticed that for some 
Linux kernel configurations, it takes ~15-30ms more for dual-stack 
libcurl to establish IPv4 connections than for IPv4 single-stack 
libcurl. After looking into this issue, it turned out that the 
regression was caused by Curl_ipv6works() function enabled in IPv6-on 
builds.


The origin for that IPv6 check was that back in the 90s it happened
that configure detected IPv6 support but then at runtime curl couldn't
actually use it.

I dare to suggest that we don't see that kind of system setups and
behavior anymore. I think maybe the time has come to make instead
rather assume that it works when built IPv6 enabled. At least I think
it is worth exploring that route first before we consider adding a new
API function for it.


This is not true. Application can be built using curl with IPv6 enabled 
(e.g. using RedHat 8 base docker image), then executed on another 
system/machine with IPv6 disabled. If I remember correctly, attempt to 
create IPv6 socket failed with error.


--
Regards,
Daniel



--

 / daniel.haxx.se
 | Commercial curl support up to 24x7 is available!
 | Private help, bug fixes, support, ports, new features
 | https://curl.se/support.html

--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html