On: Faster Base64 in Curl

[planede]

Not to play down on the improvement here, but I expected to see some comparisons to other base64 encode/decode implementations. There are many high-performance implementations out there with permissive license.

[Etheryte → planede]

One of the main upsides of Curl is that it doesn't pull in a dozen different libraries for every task at hand. The code footprint is small, the surface area for vulnerabilities is small and the reliability is high.

[planede → Etheryte]

Vendoring in is also reasonable, although it makes sense to only vendor in code that you understand and can maintain. I would still check the literature for base64 encode/decode in their place, it's not like they are the first who need a fast implementation.

[aew4ytasghe5 → Etheryte]

> The code footprint is small, the surface area for vulnerabilities is small.

I disagree. Their NIH-syndrome and ancient practices seem to be a constant source of new CVE:s [1].

1: https://curl.se/docs/security.html

[Etheryte → aew4ytasghe5]

I'm not sure I'm convinced. This is over the course of 22 years in what's arguably one of the most widely used pieces of software in the world. Keep in mind that Curl is not a tool that's ever truly "ready" so long as standards keep getting updated and new ones emerge.

[kangalioo → planede]

The real world performance implication of tedious dependency management in C

[latenightcoding → planede]

and you can find SIMD implementations fairly easily

[planede → latenightcoding]

As libcurl is used on a wide range of platforms, they do need a generic fallback implementation. But yeah, SIMD would make sense where it's available.