> As if the world needed more unsafe C code connected to the internet.

Assuming (as usual) that the code generation is solid because of curl’s reputation: why not trust it? It would be pretty bad if the generator could emit memory-unsafe code. (I don’t know.)

For a trivial example, the code just calls curl_easy_init, a bunch of curl_easy_setopt, curl_easy_perform to do the work, and curl_easy_cleanup. (It leaves comments like "CURLOPT_WRITEDATA set to a objectpointer" in a comment block on params for which "You may select to either not use them or implement them yourself" - that's presumably where you are going to write your own unsafe code :-)

Ah I see, thanks.

Oh don’t get me wrong. I trust curl and I have no reason not to trust this tool.

It’s the consumer of this tool and all the code around it that will get written I don’t trust.

libcurl is used in billions of situations.

Fair point about memory allocations in C, but often alt languages rely on other people's code which you'd implicitly trust to do the same thing. So then it becomes an argument of testing and trust. All the same, you trust strangers code or you write your own.

I suspect OP has already made up their mind on using C at all :)

:)

Stabilisers for some, but definitely not others.

and often "your own" turns out much buggier.

turtles all the way down, just pick your first turtle.