4 ms·

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

by dralley 11mo ago

donkeybeer 11mo ago
apt is C++
epolanski 11mo ago
Issues that are battle tested from ages.
- Cthulhu_ 11mo ago
  Sure, which is highly valuable information that hopefully made its way into a testing / verification suite. Which can then be used to rewrite the tool into a memory-safe language, which allows a lot of fixes and edge cases that were added over time to deal with said issues to be refactored out. Of course there's a risk that new issues are introduced, but again, that depends a lot on the verification suite for the existing tool. Also, just because someone did a port, doesn't mean it has to be adopted or that it should replace the original. That's open source / the UNIX mentality.
dboon 11mo ago
It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something you have to do ANYWAY if you’re writing e.g. a parser. This holds for many things in C
- criddell 11mo ago
  > a pointer plus length What would length represent? Bytes? Code points? Anyway, I think what you are asking for already exists in the excellent ICU library. And it's not a very easy thing to maintain. Unicode stuff changes more often than you might think and it can be political.
- steveklabnik 11mo ago
  This is just a variation of the "skill issue" argument. If it were correct, we wouldn't see these issues continue to pop up. But we do.
  - josefx 11mo ago
    I think it is more a matter of convenience. There are countless string implementations for C, some tiny projects, others part of larger frameworks like Glib. At the end of the day a C developer has to decide if they are going to pull in half of gnome to handle a few lines of IO or if they are just going to use the functions the C standard conveniently ships with. Most people are going to do the later.

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

by dralley 11mo ago

Converting parsers to Rust is not "pointless". Doing string manipulation in C is both an awful experience and also extremely fertile ground for serious issues.

donkeybeer 11mo ago

apt is C++

epolanski 11mo ago

Issues that are battle tested from ages.

Cthulhu_ 11mo ago
Sure, which is highly valuable information that hopefully made its way into a testing / verification suite. Which can then be used to rewrite the tool into a memory-safe language, which allows a lot of fixes and edge cases that were added over time to deal with said issues to be refactored out. Of course there's a risk that new issues are introduced, but again, that depends a lot on the verification suite for the existing tool. Also, just because someone did a port, doesn't mean it has to be adopted or that it should replace the original. That's open source / the UNIX mentality.

dboon 11mo ago

It’s very easy to write a string library in C which makes string operations high level (both in API and memory management). Sure, you shouldn’t HAVE to do this. I get it. But anyone writing a parser is definitely skilled enough to maintain a couple hundred lines of code for a linear allocator and a pointer plus length string. And to be frank, doing things like “string operations but cheaply allocated” is something you have to do ANYWAY if you’re writing e.g. a parser. This holds for many things in C

criddell 11mo ago
> a pointer plus length What would length represent? Bytes? Code points? Anyway, I think what you are asking for already exists in the excellent ICU library. And it's not a very easy thing to maintain. Unicode stuff changes more often than you might think and it can be political.
steveklabnik 11mo ago
This is just a variation of the "skill issue" argument. If it were correct, we wouldn't see these issues continue to pop up. But we do.
- josefx 11mo ago
  I think it is more a matter of convenience. There are countless string implementations for C, some tiny projects, others part of larger frameworks like Glib. At the end of the day a C developer has to decide if they are going to pull in half of gnome to handle a few lines of IO or if they are just going to use the functions the C standard conveniently ships with. Most people are going to do the later.