I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
There is zero reason for this to exist.
LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
11–20 of 44 posts
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#12Earlier quoted context omitted.
Well if you're an experienced C developer then yes it does.
But lots of the vulnerable C code we have in the world today was written by very experienced C developers, so I don't know that's a particularly strong argument
You must remember, a LOT of C code was written back in a time when the Internet was a more trusting environment. Lots of developers didn't even comprehend that there'd be malicious actors.
The point stands, if you're an experienced developer in one particular language then of course you will write in that language.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#13Earlier quoted context omitted.
Well if you're an experienced C developer then yes it does.
But lots of the vulnerable C code we have in the world today was written by very experienced C developers, so I don't know that's a particularly strong argument
It is essentially the same as arguing that after huffing paint for 30 years, one is qualified to huff more paint.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#14Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#15I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
A good reason is that if you want interop with other languages, C is still the lingua franca of ABIs. All scripting languages have a way to interact with C through some form of FFI mechanism. I guess you could write it in Rust and maintain C bindings to it, but that would be painful.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#16I bet almost all of the implementations of QUIC right now are open source.
I believe they are calling it out as open source because their LiteSpeed web server has non open source editions.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#17I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
A good reason is that if you want interop with other languages, C is still the lingua franca of ABIs. All scripting languages have a way to interact with C through some form of FFI mechanism. I guess you could write it in Rust and maintain C bindings to it, but that would be painful.
The rust based cloudflare implementation has C APIs. Also C bindings to rust libs are not that painful at all to maintain.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#18I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
I don't know about open source developer case.
If you develop commercial embedded software and need to be able to develop safety critical software there is no contest: C and Ada are the two best tools. Obviously you limit the coding to subset of C. MISRA C for example.
You can buy commercial tools for C and Ada that do static analysis only your source-code way past anything that you get from other languages. You can prove the absence of run time errors. No divisions by zero, no sudden application termination etc.
If you write safety critical code, you don't do dynamic memory allocation or unrestricted recursion anyway. The strengths that Rust has in memory allocation are irrelevant. Running out of memory or unlimited recursion are errors.
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#19I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
A good reason is that if you want interop with other languages, C is still the lingua franca of ABIs. All scripting languages have a way to interact with C through some form of FFI mechanism. I guess you could write it in Rust and maintain C bindings to it, but that would be painful.
Not really. We wrote a content-addressable-storage backup solution in rust[0], and one consumer is QEMU for doing backups of VMs, so we expose C bindings of our rust code[1] and use them in QEMU[2], effectively having rust async stuff handled by QEMU co-routine library. It wasn't exactly complicate or the like, required a bit of "plumbing code" but that's OK.
Allowing to get (relatively) easy C bindings is a goal and feature of rust, at least the project itself provides and maintains the rust-bindgen crate[3][4].
Having a bit bigger and slightly complex project like a backup server done in rust is such a relief compared to C or similar languages. Good speed, fast start up times like C but refactoring is really a breeze lots of safety is guaranteed and more time can be spent on fixing the semantic bugs.
[0]: https://pbs.proxmox.com/docs/introduction.html#introduction
[1]: https://git.proxmox.com/?p=proxmox-backup-qemu.git;a=summary
[2]: https://git.proxmox.com/?p=pve-qemu.git;a=blob;f=debian/patc...
Re: LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
#20Earlier quoted context omitted.
But lots of the vulnerable C code we have in the world today was written by very experienced C developers, so I don't know that's a particularly strong argument
You must remember, a LOT of C code was written back in a time when the Internet was a more trusting environment. Lots of developers didn't even comprehend that there'd be malicious actors. The point stands, if you're an experienced developer in one particular language then of course you will write in that language.
> You must remember, a LOT of C code was written back in a time when the Internet was a more trusting environment. Lots of developers didn't even comprehend that there'd be malicious actors.
Hackers were a well established thing in the 80s, with its origin "phreaking" being even older than that, so no it wasn't a naïve time when everybody though all just had the best interest possible in mind. Note also that not all crashes and breakages are intended and result of a malicious actor, or do you now argue that human entry errors just did not happen back then?
Further, most code today does not come from that era but rather originated from 90s to 2000s, with not even much of that being still around in that form.
> The point stands, if you're an experienced developer in one particular language then of course you will write in that language.
1. That's the first time you make that point, the original reply of yours has no argument whatsoever, so nothing "still stands".
2. If you're really an experienced developer in one particular language then you are aware of its shortcomings and will also look closely for languages addressing them without adding other disadvantages. Everything else would be just short-sighted, which isn't really a good virtue to have as experienced developer.
3. How comes that new code written by highly experienced developers, e.g., working on OS kernels, with a massive testing effort still let slip through buffer overflows, use after free, integer underflows, etc. etc.?