5 ms·

Experience shows that almost every time someone writes a project like this in C, applying modern fuzzing tools (e.g. AFL) will uncover bugs that let a malicious

by roca 7y ago

Experience shows that almost every time someone writes a project like this in C, applying modern fuzzing tools (e.g. AFL) will uncover bugs that let a maliciously crafted input file hijack execution and act with the privileges of whatever's running the code. It is a lot of work to remove all such bugs (and not reintroduce any) and you never know when you're done. That is a very severe problem with C that is having devastating effects on society. It is therefore irresponsible to use C for a new project like this, unless you know your code will never be exposed to malicious input. (Note that if you share the code with anyone else, it's hard to have such confidence.)

jacquesm 7y ago
> It is therefore irresponsible to use C for a new project like this So, given all this doom that hangs above my head, what should I have used?
- ncmncm 7y ago
  C++ is easy to transition to. The powerful libraries growing up around it make dropping down to the dangerous level mentioned largely unnecessary, without giving up performance.
  - roca 7y ago
    Every time you use references in C++ you are "dropping down to the dangerous level".
    - ncmncm 7y ago
      Passing things by reference is safe. Any other use is mostly just pointless; it what reference types are for. If you are doing something else with them, it easy to stop.
      - roca 7y ago
        Passing parameters by reference is certainly not always safe. You can, for example, pass a reference to a deref'ed unique_ptr into a function call, while the function call does something that clears the unique_ptr. If you want to avoid objects containing references (or raw pointers), then you have to avoid using lots of standard library stuff --- `string_view`, C++20 `span`, or even STL iterators.
        ncmncm 7y ago
        Now you are talking about pointers.
        roca 7y ago
        There isn't much difference between references and pointers. That is the problem.
        ncmncm 7y ago
        A reference only ever points at one thing, from birth to death, and it always points at something.
        roca 7y ago
        No, it is entirely possible to delete the underlying object so a reference is left dangling. See https://github.com/isocpp/CppCoreGuidelines/issues/1038 https://github.com/isocpp/CppCoreGuidelines/issues/1038 for example.
- MiroF 7y ago
  Rust or modern C++, although the abstractions on the latter are leaky
- roca 7y ago
  I don't know all your requirements so it's hard to say. It is very likely that Rust would be a good choice, especially if the libraries you used have Rust equivalents.
  - jacquesm 7y ago
    Isn't Rust right now (1) still a niche language (2) terribly slow to compile (3) a bad fit in the first place since I don't actually know the language and (4) still immature? As for libraries, the most important ones that I rely on deal with the loading of .wav files, writing of midi files, decoding of mp3s and fftw ( http://www.fftw.org/ http://www.fftw.org/ ).
    - roca 7y ago
      1) Define "niche language". Lots of people are using Rust in production. Rust isn't in the top 10 most popular languages, but it is in the top 100, and rising. 2) Compilation speed is a problem for some projects, but not for small projects like yours. 3) Understandable, but writing exploitable code because you don't know a suitable alternative language very well is not a good long-term situation. Maybe you should do something about that. 4) Define "immature". It's not one of the world's most mature languages, but it is definitely mature enough to write production code for many contexts. In many ways C is the language that needs to grow up. There are Rust libraries for all those things (including Rust bindings for FFTW itself), though I can't speak to their quality. I can confidently say that using Rust libraries in a new Rust project is a lot easier than using C libraries in a new C project, especially if you're not on Linux.
      - jacquesm 7y ago
        > Lots of people are using Rust in production. Rust isn't in the top 10 most popular languages, but it is in the top 100, and rising. I've yet to come across anybody outside of the HN crowd that knows about or uses Rust. Not a single company that I looked at in the last year used Rust, that's 41 of them and I asked every one of them which programming languages are in use. > Compilation speed is a problem for some projects, but not for small projects like yours ECT cycle (edit, compile, test) is a pretty big factor during early stage development. Running a test in a second versus running a test in ten seconds would ruin my day. I'm not sure what the current speed of compilation is for Rust but the only time that I looked at it (very early on) it was so slow as to be unusable from my perspective. I'd hope that has substantially improved. Think of what I'm doing as explorative programming, I'm both trying to understand the problem and trying to solve it at once. > Understandable, but writing exploitable code because you don't know a suitable alternative language very well is not a good long-term situation. That may be true. At the same time, Rust may not be a good long term solution either, languages come and languages go, and before I invest a year or so into a new eco-system I'd like to see it has staying power. It is interesting that you recommended Rust and not say Java which has pretty good performance, is memory safe and is in production for well over a decade, for this particular use case I would choose that over Rust. > Define "immature". It's not one of the world's most mature languages, but it is definitely mature enough to write production code for many contexts. There isn't a month or we see an announcement of the next point release of Rust on HN. I don't have the luxury of tracking a moving target next to working a full time job and having a family, then doing this hobby project besides. If Rust wants to see mainstream adoption for stuff like this because you seriously believe that writing a new project in C is irresponsible (which smacks of FUD, and is one of the reasons why I think Rust is one of the more toxic language communities on the internet, I have never seen a Java proponent use that kind of language) then I hope you agree that getting Rust to some kind of long-term stable form in the very near future is a must. This whole 'the sky is falling' tactic is rather off-putting, at least, it is to me. The same happened to perl, which was supposed to be - and still is according to some - the best thing since sliced bread. > There are Rust libraries for all those things (including Rust bindings for FFTW itself), though I can't speak to their quality. That's good to hear. > I can confidently say that using Rust libraries in a new Rust project is a lot easier than using C libraries in a new C project For you, as a Rust user, yes. But you are forgetting that for me that is not at all easier, and that using C libraries in a new project is a lot easier than using Rust libraries for me because I happen to know how that works. Vantage point is a bit of an issue here, I take it that you are fluent in both Rust and C and that you have decided to hitch your wagon to Rust. I'm fine with that and no doubt in the long run you will be proven right but to me it smacks of 'you should do as I do' rather than that it is the best for me. Learning a new language just for some project is a very high degree of friction to add, it would slow me down tremendously and it might lead to the project being abandoned rather than progressing at a quite acceptable speed given my constraints in time. > especially if you're not on Linux. I wouldn't dream of developing software on anything else, but I totally respect other people's choices in their platforms.
- switch007 7y ago
  You wrote "Even if I know there are better alternatives out there"...so you tell us! You also wrote: "Not pretty, known to hurt you if you abuse it but still plenty sharp and well capable of doing the job if you treat it well." To me it seems you know it can be dangerous, but like it too much not to use it.
  - jacquesm 7y ago
    > Even if I know there are better alternatives out there I could have chosen Java, Python, Go or C++ instead. Instead I chose the tool I'm most familiar with because that will get me focused on the problem rather than on the tool. It's a disadvantage of getting older: there is less time left to waste. > To me it seems you know it can be dangerous, but like it too much not to use it. It is mostly a familiarity thing, not a like or dislike.

by roca 7y ago

jacquesm 7y ago

> It is therefore irresponsible to use C for a new project like this So, given all this doom that hangs above my head, what should I have used?

ncmncm 7y ago
C++ is easy to transition to. The powerful libraries growing up around it make dropping down to the dangerous level mentioned largely unnecessary, without giving up performance.
- roca 7y ago
  Every time you use references in C++ you are "dropping down to the dangerous level".
  - ncmncm 7y ago
    Passing things by reference is safe. Any other use is mostly just pointless; it what reference types are for. If you are doing something else with them, it easy to stop.
    - roca 7y ago
      Passing parameters by reference is certainly not always safe. You can, for example, pass a reference to a deref'ed unique_ptr into a function call, while the function call does something that clears the unique_ptr. If you want to avoid objects containing references (or raw pointers), then you have to avoid using lots of standard library stuff --- `string_view`, C++20 `span`, or even STL iterators.
      - ncmncm 7y ago
        Now you are talking about pointers.
        roca 7y ago
        There isn't much difference between references and pointers. That is the problem.
        ncmncm 7y ago
        A reference only ever points at one thing, from birth to death, and it always points at something.
        roca 7y ago
        No, it is entirely possible to delete the underlying object so a reference is left dangling. See https://github.com/isocpp/CppCoreGuidelines/issues/1038 https://github.com/isocpp/CppCoreGuidelines/issues/1038 for example.
MiroF 7y ago
Rust or modern C++, although the abstractions on the latter are leaky
roca 7y ago
I don't know all your requirements so it's hard to say. It is very likely that Rust would be a good choice, especially if the libraries you used have Rust equivalents.
- jacquesm 7y ago
  Isn't Rust right now (1) still a niche language (2) terribly slow to compile (3) a bad fit in the first place since I don't actually know the language and (4) still immature? As for libraries, the most important ones that I rely on deal with the loading of .wav files, writing of midi files, decoding of mp3s and fftw ( http://www.fftw.org/ http://www.fftw.org/ ).
  - roca 7y ago
    1) Define "niche language". Lots of people are using Rust in production. Rust isn't in the top 10 most popular languages, but it is in the top 100, and rising. 2) Compilation speed is a problem for some projects, but not for small projects like yours. 3) Understandable, but writing exploitable code because you don't know a suitable alternative language very well is not a good long-term situation. Maybe you should do something about that. 4) Define "immature". It's not one of the world's most mature languages, but it is definitely mature enough to write production code for many contexts. In many ways C is the language that needs to grow up. There are Rust libraries for all those things (including Rust bindings for FFTW itself), though I can't speak to their quality. I can confidently say that using Rust libraries in a new Rust project is a lot easier than using C libraries in a new C project, especially if you're not on Linux.
    - jacquesm 7y ago
      > Lots of people are using Rust in production. Rust isn't in the top 10 most popular languages, but it is in the top 100, and rising. I've yet to come across anybody outside of the HN crowd that knows about or uses Rust. Not a single company that I looked at in the last year used Rust, that's 41 of them and I asked every one of them which programming languages are in use. > Compilation speed is a problem for some projects, but not for small projects like yours ECT cycle (edit, compile, test) is a pretty big factor during early stage development. Running a test in a second versus running a test in ten seconds would ruin my day. I'm not sure what the current speed of compilation is for Rust but the only time that I looked at it (very early on) it was so slow as to be unusable from my perspective. I'd hope that has substantially improved. Think of what I'm doing as explorative programming, I'm both trying to understand the problem and trying to solve it at once. > Understandable, but writing exploitable code because you don't know a suitable alternative language very well is not a good long-term situation. That may be true. At the same time, Rust may not be a good long term solution either, languages come and languages go, and before I invest a year or so into a new eco-system I'd like to see it has staying power. It is interesting that you recommended Rust and not say Java which has pretty good performance, is memory safe and is in production for well over a decade, for this particular use case I would choose that over Rust. > Define "immature". It's not one of the world's most mature languages, but it is definitely mature enough to write production code for many contexts. There isn't a month or we see an announcement of the next point release of Rust on HN. I don't have the luxury of tracking a moving target next to working a full time job and having a family, then doing this hobby project besides. If Rust wants to see mainstream adoption for stuff like this because you seriously believe that writing a new project in C is irresponsible (which smacks of FUD, and is one of the reasons why I think Rust is one of the more toxic language communities on the internet, I have never seen a Java proponent use that kind of language) then I hope you agree that getting Rust to some kind of long-term stable form in the very near future is a must. This whole 'the sky is falling' tactic is rather off-putting, at least, it is to me. The same happened to perl, which was supposed to be - and still is according to some - the best thing since sliced bread. > There are Rust libraries for all those things (including Rust bindings for FFTW itself), though I can't speak to their quality. That's good to hear. > I can confidently say that using Rust libraries in a new Rust project is a lot easier than using C libraries in a new C project For you, as a Rust user, yes. But you are forgetting that for me that is not at all easier, and that using C libraries in a new project is a lot easier than using Rust libraries for me because I happen to know how that works. Vantage point is a bit of an issue here, I take it that you are fluent in both Rust and C and that you have decided to hitch your wagon to Rust. I'm fine with that and no doubt in the long run you will be proven right but to me it smacks of 'you should do as I do' rather than that it is the best for me. Learning a new language just for some project is a very high degree of friction to add, it would slow me down tremendously and it might lead to the project being abandoned rather than progressing at a quite acceptable speed given my constraints in time. > especially if you're not on Linux. I wouldn't dream of developing software on anything else, but I totally respect other people's choices in their platforms.
switch007 7y ago
You wrote "Even if I know there are better alternatives out there"...so you tell us! You also wrote: "Not pretty, known to hurt you if you abuse it but still plenty sharp and well capable of doing the job if you treat it well." To me it seems you know it can be dangerous, but like it too much not to use it.
- jacquesm 7y ago
  > Even if I know there are better alternatives out there I could have chosen Java, Python, Go or C++ instead. Instead I chose the tool I'm most familiar with because that will get me focused on the problem rather than on the tool. It's a disadvantage of getting older: there is less time left to waste. > To me it seems you know it can be dangerous, but like it too much not to use it. It is mostly a familiarity thing, not a like or dislike.