Comment by infogulch | Hacker News Reader

Comment by infogulch | Hacker News Reader

Parent Full thread

For my first C class in uni I wrote a curses-style CLI spreadsheet tool with a csv parser, reverse cell reference table, automatic modification-based recursive recalculation, a basic formula parser, an infix notation to reverse polish notation "compiler", and a stack-based RPN evaluator (I may have gone a bit overboard on that assignment). The one multi-user unix server for all students that I wrote it on (named 'foley', some CS reference I think) had an ancient gcc compiler that compiled it just fine, but when run it would segfault. Hardly surprising, I created hundreds of segfaults, but this one would only segfault if I used -O0 and didn't add any logging statements. That's right, it ran fine with any level of optimization above 0 or if I used any logging statements, and only segfaulted on -O0. Utterly infuriating and flagrantly defied my expectations. I got help from some patient soul I found on freenode ##c (I wish I could remember their name) who didn't see any obvious issue or warning and couldn't reproduce any segfault with their much more recent compiler. -Wall+++, asan, nothing cracked it. Everything else was exhausted: it must be the compiler. But I couldn't just update the compiler package because it was a multi-user server and I had zero permissions, so I ended up bootstrapping a 10-years newer gcc through multiple intermediate versions and installing it in my profile (quotas be damned) and used that. It didn't segfault on -O0 anymore. I haven't voluntarily used C since.

This is not a good anecdote - You hit a 10 year old bug because your sysadmin was too lazy to update gcc and then formed a bad impression of the software?

Guess what, if you install a 10 year old version rust none of your code would not compile at all. Your logic is so flawed its hard to believe you are being serious. If anything it's impressive that a 10 year old C compiler worked most of the time when most other languages are not stable on these timescales.

The oldest rustc version I target (for a tiny project, admittedly) is over 6 years old, and it's fine. When code works it also works on the latest release. When code doesn't work I get a reasonable compile-time error message, not a mysterious segfault at runtime.

It's not easy, even in a few hundred lines I had to remove many conveniences to go that far back, but it's very legible. The compiler has my back, I'm never confused about whose fault it is.

Rust is young, but I don't expect this to be any different in 2030.

> Guess what, if you install a 10 year old version rust none of your code would not compile at all.

Rust was not stable in 2012 yet.

I do agree with your overall point though.

That's not related to C, except in the sense that GCC is written in C. GCC was just emitting incorrect code because it had a bug in its code generator. If there's a bug in the LLVM code generator (which is written in C++), rustc might end up doing the same thing.

If you write the compiler in Rust it could still happen. Rust code (that compiles) has less bugs than the corresponding C but not zero bugs.

It doesn't sound like you went overboard, it sounds like a good project. Maybe you should have written it in Perl 5.001 though.

GCC is written in C++

There are small parts of GCC that are written in C++, but at the time when universities had "one multi-user unix server for all students" it was 100% C.

and there was no LLVM :)

Nor Rust!

Yeah, but that was 40 years ago, back when GCC still stood for GNU C Compiler.

I had pegged it as between 20 and 30 years ago, but someone pointed out that the author said they tried using asan. 40 years ago most universities didn't have Unix boxes accessible to random undergraduates at all.

GCC started having parts written in C++ 12 years ago: https://lwn.net/Articles/542457/

Because it was C I couldn't be sure it was the compiler's fault until I really exhausted every other option. Maybe spent 100h between a few people getting to the end of it. If I had written in safe Rust (I would have, I wasn't doing anything weird) and it segfaulted I'd know immediately that the compiler was the problem because you can't make safe rust segfault.

Yes, that's true.

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.

Valgrind 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.

You 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.

I 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.

> 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.

And vice versa; Frama-C doesn't attempt to prove the absence of data races, last I checked.

In fact there exists a plugin that can do that but it is currently not free:

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)

OP mentions asan so valgrind definitely did exist - it's more than twice as old as asan

Hmm, that's interesting—that seems like an inconsistency in the story. OP, what year was this?

I 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)

Sure, 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.)

.. 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

Yeah, 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.

I am quite sure stuff like Insure++ and Purify did exist.

Yes, Purify surely existed. I've never heard of a university leasing out Purify licenses to undergrads. I don't know anything about Insure++.

On my days that kind of software was accessible in all universities, with the right connections.

valgrind came out 20 years ago, so yes, it definitely existed 10 years ago.

20 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.

Valgrind 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?

Right, but it is pretty great for deterministic segfaults.

Yes perl may have been a better choice for the projects sake, but alas the course was apparently a trial-by-~fire~segfault of C + string processing. Loved PCRE though... hmm I wonder if you could do it with just a regex...

I will be very surprised if you can write a working spreadsheet in a PCRE regex. Perl itself permits you to embed arbitrary Perl code in a "regex", though.

GCC is being written in C++ for about a decade now.

Reply on news.ycombinator.com