5 ms·
Or he could do the normal thing and run valgrind to instantly see exactly where the problem is. I don't even disagree with the premise, but these are straw man
by andrewchambers 4y ago
Or he could do the normal thing and run valgrind to instantly see exactly where the problem is. I don't even disagree with the premise, but these are straw man arguments.
- kragen 4y agoValgrind didn't exist then. (Next you're going to say ASan and UBSan. Those didn't exist either.) They (he?) could have run GDB and disassembled the code around the crashing instruction and verified that the machine code there didn't make any fucking sense. But that implies they knew assembly language well enough to recognize when their compiler was spewing nonsense, which is a couple of steps above "can read working assembly emitted by the compiler" or even "can write applications in assembly language". Even with Valgrind it can be tough to distinguish whether your output code is wrong because of a bug in the compiler or because your code was just wrong. There was a change to GCC a few years back that introduced security holes into the FreeBSD and NetBSD kernel because it just threw away code that would only be invoked in "undefined behavior" scenarios. Signed integer overflow I think.
- andrewchambers 4y agoYou are unfairly comparing ancient C with modern rust - Try comparing modern C with modern rust to avoid making a straw man argument. Like I said, I don't even disagree, I still think you are just doing everyone a disservice with this line of reasoning. He said if he had used rust - I am saying if he had used C when rust was available 1. The bug would have been fixed. 2. He could have used valgrind. Modern C also has something called ubsan, and another thing called frama-C. These tools may be inferior to what rust has, but ignoring they exist or comparing 10+ year old C with modern rust is a bad faith argument.
- kragen 4y agoI agree, I don't think that a bug in GCC last millennium is a very strong argument for using Rust instead of C today, though such arguments do exist. However, I also don't think they particularly help you to distinguish a compiler bug from an error in your understanding of the language semantics, although they sure do help a lot with everyday errors. With respect to questions of inferiority or superiority, keep in mind that Valgrind and UBSan are only dynamic checkers; they don't help at all with errors that don't occur in your testing. Frama-C is a static checker more similar to Rust's capabilities, but much more limited, but also with cscope-like abilities for reverse-engineering existing source bases. The great advantage these three tools (and ASan) have is that you don't have to rewrite your C in Rust in order to use them.
- KsassPeuk 4y ago> but much more limited I agree and I disagree ;) I agree because having a type system that directly provides the guarantee that whole classes of runtime error cannot happen provides fast feedback during development at a low cost. I disagree because even in a press button (+ tuning) approach, you can prove things with Frama-C that the Rust compiler cannot prove (reason why there is runtime bound-checking, implementation defined behavior for integer overflow and so on in Rust). But also because you can prove much more advance properties than "just" absence of runtime errors.
- kragen 4y agoAnd vice versa; Frama-C doesn't attempt to prove the absence of data races, last I checked.
- KsassPeuk 4y agoIn fact there exists a plugin that can do that but it is currently not free: https://frama-c.com/fc-plugins/mthread.html https://frama-c.com/fc-plugins/mthread.html (And by the way since it is not done by typing it is hard to use on legacy code)
- jcelerier 4y agoOP mentions asan so valgrind definitely did exist - it's more than twice as old as asan
- kragen 4y agoHmm, that's interesting—that seems like an inconsistency in the story. OP, what year was this?
- jcelerier 4y agoI don't see any inconsistency. Universities still have multi-user unix servers for students in 2022 - at Bordeaux there's a few 64/128 thread ones with as many gigabytes of RAM, which leaves a lot of room for doing work during class. (And most likely they would be running some Debian LTS like Jessie or Stretch)
- kragen 4y agoSure, I'm using a multi-user Unix server right now in another window. The key point was that there was just one server for all the undergraduates. (And that they had to worry about a private install of GCC using up their disk quota.)
- jcelerier 4y ago.. the uni I'm involved in still has a 1gb quota per student ~ afaik which ... needs some contorsion to be able to fit a GCC build, for sure
- kragen 4y agoYeah, you can't build modern GCC inside the 1GB quota, but you can probably build it in /tmp or /var/tmp or /scratch or something. The actual built compiler is under 50 MB in GCC 8. And if you're really cramped on quota you can gzexe it, at the cost of painfully slow startup times.
- pjmlp 4y agoI am quite sure stuff like Insure++ and Purify did exist.
- shaklee3 4y agovalgrind came out 20 years ago, so yes, it definitely existed 10 years ago.
- kragen 4y ago20 years ago nearly all universities could afford more than a single Unix box for all the undergraduates to share. At that point it was mainstream to buy a cheap US$300 ATX box and run Linux on it, so you could have one per student or one per dozen students, rather than one for the whole undergraduate student body. The Rio Receiver came out 21 years ago. That was a Linux box sold as a consumer electronics stereo component; it grabbed MP3s over Ethernet to play them. I don't remember how much it cost but it was less than US$300. But apparently the original author tried using asan? That seems like an inconsistency in the story.
- kaba0 4y agoValgrind only outputs errors on codepaths that got run. Which sure, if it is a deterministic segfault it would catch, but let’s say you have a race condition and only get segfault 1 times out of 100, and it may not even happen on valgrind?
- kragen 4y agoRight, but it is pretty great for deterministic segfaults.