63

A friend of my family asked me for a bit of help as he learns to program (in the C language). As we were talking, he expressed frustration about having a hard time understanding the error messages his compiler (GCC) is giving him when he makes errors. He does not understand all the terms used, and sometimes it's their combination which is beyond his comprehension. He was asking me "How come the compiler documentation doesn't include longer explanations of the error messages?" - and I didn't have a good answer for him.

I myself - as a more experienced programmer - am very rarely in this situation, but those rare occurrences do happen - some exotic error message I hadn't encountered before. I manage to get by with looking for the error message in a search engine, but apparently that doesn't always work for him - especially since the errors he encounters are more common and occur in multiple distinct cases, which he has trouble relating to his own.

So, how should a novice programmer approach the challenge of understanding compiler error messages? Specifically, with the combination of C and GCC?

einpoklum
  • 2,478
  • 1
  • 13
  • 30
  • 7
    _"So, how should a novice programmer approach the challenge of understanding compiler error messages?"_ /sarcasm The 1st skill needed is to be able to read every bit from the compiler message, including to relate it with the very context. /sarcasm off. It rarely turns out to be a flaw, or bug in the compiler. – πάντα ῥεῖ May 18 '18 at 18:27
  • 10
    @MasonWheeler: A novice often does not choose which compiler to use when undergoing training. And GCC is a common denominator of many, many systems... – einpoklum May 18 '18 at 18:38
  • 6
    @πάνταῥεῖ: 1. Some people don't have that skill, and a glossary would help them develop it. Hell, some people don't even know the meaning of some of the individual _words_ in error messages. 2. I didn't understand your comment after the sarcasm ended; I didn't say anything about compiler bugs/flaws. – einpoklum May 18 '18 at 18:44
  • 5
    @einpoklum: He turned off the sarcasm a bit too early. – Robert Harvey May 18 '18 at 18:55
  • 3
    I'm so confused. How is this not asking for [Stack Overflow c](https://stackoverflow.com/questions/tagged/c)? – candied_orange May 18 '18 at 19:37
  • 6
    Break a complex line of code having problems with (compile time or runtime) into several smaller, simpler lines (connected by [temporary] variables) to get more specific on the source of error. – Erik Eidt May 18 '18 at 21:29
  • @ErikEidt: Definitely good advice to give novices (and non-novies). – einpoklum May 18 '18 at 21:35
  • 2
    I've been experienced enough to not be bothered by this for a long time, but there was something refreshing about [the error messages that came from some MPW compilers](http://www.ralentz.com/old/mac/humor/mpw-c-errors.html). And of course a little humor: `This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message`. – dmckee --- ex-moderator kitten May 19 '18 at 03:58
  • 25
    When it comes to GCC C++ template errors, I find if I stop reading after "Error " and study the source file(s), I find the error quicker, with an added side effect of maintaining my sanity, than if I read the actual error given by GCC..... – mattnz May 19 '18 at 05:47
  • 5
    That will not be the only frustration you will have. – Billal Begueradj May 19 '18 at 08:34
  • The only time I need to look up compiler error terms is when I'm compiling large third party projects, such as building packages. Say, I have no idea of the type & intended purpose of any declared variable to know the syntactical error the compiler is complaining about, to make sense of the error or warning. However, when I write my own large pieces of codes, I know what everything is & what they're supposed to do, the compiler just have to bring the error or warning up. This is because I never memorize any of the error terms. – Dehbop May 19 '18 at 10:54
  • 19
    The solution is obvious: Use a compiler with less confusing output. I suggest [rmcc](http://somewhere.fscked.org/proj/rmcc/). It prints `Yes.` or `No.` depending on if your code compiled or not. Instantly takes away the frustration from not understanding long and pointless messages! – pipe May 19 '18 at 11:39
  • @pipe: Awesome :-) – einpoklum May 19 '18 at 11:47
  • 21
    C is not a good language for beginners — and you have stumbled upon one of the reasons. That being said, Clang tends to offer much better errors that might also be more appealing to beginners. – Theodoros Chatzigiannakis May 19 '18 at 14:43
  • @pipe And make sure they use an editor without confusing error messages too. I suggest [ed](https://www.gnu.org/fun/jokes/ed-msg.html) – mu is too short May 19 '18 at 19:15
  • 3
    @TheodorosChatzigiannakis: Don't start a religious war here about which language is better to study first. Plus, it's not up to me anyway. – einpoklum May 19 '18 at 20:03
  • 1
    @TheodorosChatzigiannakis He didn't ask for advice. The question is clear. If you want to discuss languages, this is _not_ the place. – pipe May 19 '18 at 20:27
  • 1
    The answer to your friend's "Why?" question is that programming was traditionally computer programming was done by people with more training and expertise, so they didn't need error messages to be explained to them, they could understand them from basic principles. But languages have become more complex, and non-experts do more programming now. – Barmar May 20 '18 at 04:21
  • 7
    Is your friend sure that C is a good language for a beginner programmer? I would not characterize C as a good language for a beginner programmer. Why are they bent on learning C? – Eric Lippert May 20 '18 at 13:18
  • 2
    It's not a decision he's making, and he has no context to be sure or even form a solid opinion. He's learning C because he's in some course or academic program which teaches C. (Actually, my own Alma Mater teaches C as a first programming language to all undergraduate students.) – einpoklum May 20 '18 at 13:58
  • Clang has been known for better error messages compared to GCC, maybe check if it makes a difference for your friend? – Kos May 20 '18 at 18:51
  • 3
    Old pepperidge farm remembers: Back in my day, *everyone* learned to program with C lang. When you know how things work in the grass level, you will understand higher level languages much better :) – Juha Untinen May 21 '18 at 11:56
  • 1
    Anyone here tried Ada? The compiler is the best I have ever used in this respect. It tells you there was an error, where it is, what it is, and then gives you a suggestion of what it thinks you should do to fix it. – Baldrickk May 21 '18 at 13:13
  • 1
    @Baldrickk: Point taken, but please don't start a discussion in the comments on trying Ada. – einpoklum May 21 '18 at 14:36
  • @einpoklum it was just an example – Baldrickk May 21 '18 at 14:44
  • @JuhaUntinen: I'm the same generation of C-taught developer, and I love knowing what happens under the hood, but you can't always compare old and new development styles. That's effectively like expecting a F1 pilot to know how to race horses. Sure, a person who knows both is likely an enthusiast and more likely to be an above average F1 pilot, but that doesn't mean that knowledge about horse racing is _necessary_ in this day and age. – Flater May 22 '18 at 10:54
  • 1
    @EricLippert: There are some merits to learning C first. It's one of the few languages left that you can still hold the entire language in your head all at once. K&R is only 232 pages long. C requires you to think about the hardware (at least a little), which is valuable for the same reasons that a person studying math should learn long division, even though they'll probably use a calculator for the rest of their life. C is the foundation for all of the other curly-brace languages. – Robert Harvey May 22 '18 at 15:22

9 Answers9

163

A few useful techniques:

  • Turn on -Wall and -Werror. It might seem counterintuitive when you're struggling with deciphering error messages to create even more error messages, but the warnings are typically easier to understand and closer to the actual source of the problem, and ignoring them can lead to errors that are difficult to understand.
  • Just try to fix the first error in the list. Often errors compound on each other, leading to later error messages not really being actual errors. Fix one and recompile. You'll get better at fixing multiple error messages when you gain more experience.
  • Use the newest compiler version possible. C is an extremely stable language. Therefore, a huge part of the improvements in newer compilers isn't to add language features, but to improve the developer experience, including better error messages. Many widely-used linux distributions have very old versions of gcc by default.
  • Program incrementally. Don't try to write a ton of code before compiling. Write the shortest amount possible that will still compile. If you've only changed one line since the last time it compiled cleanly, it's a lot easier to figure out which line contains the actual problem.
  • Write unit tests. It makes you more confident to make clarifying refactoring changes when fixing compile errors.
Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 23
    A good IDE can also greatly help the experience by eg. underlining errors in red. – BlueRaja - Danny Pflughoeft May 19 '18 at 02:02
  • 86
    "Program incrementally. Don't try to write a ton of code before compiling. Write the shortest amount possible that will still compile. If you've only changed one line since the last time it compiled cleanly, it's a lot easier to figure out which line contains the actual problem." This, so much this. Also most IDEs will warn you if you write code that won't compile, and highlight the erros. – Polygnome May 19 '18 at 10:34
  • @Polygnome yep that is probably the best advice on programming I read in a long time. – mathreadler May 19 '18 at 23:00
  • While this is good advice for programmers in general, most of it is not IMHO very helpful to novices. They get short programming assignments, where there's nothing much to increment. There aren't multiple units to test; and the issue is with compilation, not with logic errors resulting in incorrect runtime behavior. The first two suggestions are spot-on though. – einpoklum May 20 '18 at 07:27
  • 4
    @einpoklum: don't underestimate the third option; compiler error messages have improved a lot. In a similar vein, use several compilers (e.g. gcc and clang) - catches more errors/warnings and one of them might have a better diagnostic for a specific issue than the other. – Mat May 20 '18 at 09:24
  • 19
    @einpoklum: writing things more incrementally is **very** spot on, especially for beginners. Heck, if you believe "short programming assignments" cannot be done incrementally, by splitting them into several small functions and implement and compile them one-by-one, you should try to improve that skill for yourself.. – Doc Brown May 20 '18 at 09:54
  • 1
    @DocBrown Indeed, the whole point of "short programming assignments" is to start people on the incremental approach; it makes the iterations/increments as small as possible, which makes them more accessible to beginners. If nothing else, surely these assignments at least take multiple lines of code - and even if those couldn't be tested separately (true for the very simplest assignments), they sure as hell can be *compiled* separately. After all, the novices probably need to think about those lines separately anyway - the skill to handle entire blocks of code as one increment is quite advanced – Luaan May 21 '18 at 08:32
  • 1
    @Luaan: absolutely. However, someone trying "to handle entire blocks of code as one increment" is not an advanced programmer, that is someone who wrongly believes he is an advanced programmer. – Doc Brown May 21 '18 at 08:58
  • 4
    A trick that helped me: if the error message mentions Line N, check Line N-1. For example, if you're missing a semicolon on line 17, the error message will say that something in wrong with line 18. This is because the compiler was expecting a semicolon but got something else, on the next line, instead. – user2023861 May 21 '18 at 15:36
  • 1
    For the second point, fixing the first error, I'd suggest turning on `-Wfatal-errors`. Helps a lot to cut down on the amount of garbage GCC can print out. Besides, anything after the first error has a very large chance to be due to the first error. – csiz May 21 '18 at 18:09
  • The incremental approach can work in reverse. When encountering errors in your program, try commenting out the troublesome portions until the program does compile, then start to add the code back in a little bit at a time. – jxh May 21 '18 at 19:34
56

Your friend does not need a glossary. A glossary will not help him. What he needs is better intuition about what to do when compiler errors occur.

C compiler errors are not as intuitive as, say, C# compiler errors, for many reasons mostly having to do with the "close to the metal" nature of C. Solving compiler errors in C is not a pattern matching exercise, because the error you receive may have nothing to do with the actual problem. Unlike C# or Java, where an error message typically maps to a precise code location and problem, errors in C are likely to be numerous and far afield.

An example of this is "semicolon expected" or any number of syntax errors that indicate the parser got hung up on something (not necessarily a semicolon). Or something like "unexpected forward declaration," an error which, when I see it, invariably means that I got capitalization wrong in one of my .h files, but which does not point to the .h file as the source of the problem.

Your friend's strategy shouldn't be to pattern match this to a list of errors and solutions; it should be to understand the syntax and specification of the C language well enough to figure out what the actual problem is.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 4
    Think about this example: "lvalue required as left operand of assignment etc. etc." - would it not be a good idea to get a 3-sentence explanation of what's an lvalue, and why it's required, from a glossary? Few beginner programming courses I know of teach people what "lvalues" and "rvalues" are. Of course "semicolon expected" can't be explained much further, although to be honest, some non-native-English-speakers don't know that a `;` is called a "semicolon". – einpoklum May 18 '18 at 18:42
  • 17
    No. The idea is to know the language well-enough to know that you can't make an assignment to a numeric expression, but only to a variable. You don't have to know what an lvalue is at all, which is why they don't teach that in beginner courses. – Robert Harvey May 18 '18 at 18:45
  • 8
    But aren't you essentially suggesting that programmers not write erroneous code and will thus avoid error messages they can't understand? – einpoklum May 18 '18 at 18:48
  • 18
    Essentially, yes. But practically, that's not possible. I've been doing this for a very long time and I still get obscure compiler error messages every time I write a C program. I seldom bother to read those messages and try to understand them, however; instead, I look at where the error message is pointing, and because I know what the basic syntax structure of a C program is supposed to look like, I can spot the problem relatively quickly without spending time deciphering error messages. – Robert Harvey May 18 '18 at 18:50
  • 36
    To put it another way, asking for a glossary to understand compiler errors is a bit like reading the dictionary to understand the English language; that's not quite how it works. You learn and understand English by reading and writing it, not reading the dictionary. – Robert Harvey May 18 '18 at 18:54
  • 9
    You do realize that people who learn the English language _do_ use dictionaries _a lot_. Of course they don't rely mostly on dictionaries, but that is a useful resource to have. Ha, vanquished by your own metaphor... :-) – einpoklum May 18 '18 at 18:55
  • 14
    *[shrug]* If you're not using a dictionary to merely *supplement* your already-existing knowledge of English, I would suggest that you're doing it wrong. The last thing I would suggest is anything that causes novice programmers to get hung up on vocabulary any more than they already are. Programmers don't need more words; they need more *skill.* – Robert Harvey May 18 '18 at 18:56
  • 8
    @einpoklum: as a non-english native speaker, I can tell you I needed several years until I could use an english dictionary in a sensible way. And I agree very much with Robert here that the exact text of a compiler's error message - especially C and C++, but other languages too - is often not important - the location of where the error occurs is. – Doc Brown May 18 '18 at 19:28
  • 13
    @einpoklum, a glossary is not going to help here. The description of the word 'lvalue' is likely to be either too technical for a beginner or along the lines of 'that what can be on e left-hand side of an assignment' which is just as unhelpful. – Bart van Ingen Schenau May 18 '18 at 19:30
  • 1
    @RobertHarvey: The C Standard doesn't use the term "variable". Compilers' error messages tend to use the terminology described in the Standard, notwithstanding the fact that it uses terms like "object" in various inconsistent ways. – supercat May 18 '18 at 22:41
  • 5
    @supercat: All the more reason to get better at C instead of getting better at vocabulary. – Robert Harvey May 18 '18 at 22:45
  • 1
    @ supercat: I've been programming in C, and often getting paid for it, for longer than I care to remember (long enough that K&R was my original language manual), yet I can't recall ever actually looking at the C standard. – jamesqf May 19 '18 at 01:32
  • 'for many reasons mostly having to do with the "close to the metal" nature of C' - Don't you mean something more like hacks in the language design to allow writing a compiler to run on an underpowered (at least relative to today) machine? I don't see how "close to the metal" could justify not being able to diagnose misplaced semicolons and forward declarations. – npostavs May 19 '18 at 13:43
  • 3
    @npostavs: The executable product of a language like C# contains metadata that assists with the debugging process, whereas C usually compiles down to bare machine code. That's what I mean by "close to the metal." – Robert Harvey May 19 '18 at 14:10
  • @jamesqf: It used to be that if the Standard said something was Undefined Behavior, but precedents for similar implementations were unambiguous, compilers would seek to honor precedent. That has become unfashionable, however. Something like `unsigned mulMod65536(unsigned short x, unsigned short y) { return (x*y) & 65535u;}` may sometimes cause weird side-effects on gcc. And I don't know anything other than the Standard which would explain why hex constants ending in `e` need to be separated by a following `+` or `-` by whitespace. – supercat May 19 '18 at 16:05
  • @Robert Harvey: Well, so does your C program if you compile with the -g flag (in gcc and at least some other compilers). Of course it does assume you have the source code... – jamesqf May 19 '18 at 19:03
  • 1
    @einpoklum "people who learn the English language do use dictionaries a lot" - Actually, most people who learn the English language don't even touch a dictionary before they are talking fluent English: They are simply not able to read them, they are too young for that ;-) – cmaster - reinstate monica May 19 '18 at 21:51
  • 1
    @npostavs Well, "close to the metal" may not be the best term for it, but C certainly has some definitions in it that may surprise even experienced C programmers. The `lvalue` definition is common enough for the experienced to know it, but take for instance the fact that `array[i]` is actually evaluated equivalent to `*(array + i)`, rendering the `[]` operator commutative: `array[i]` <=> `*(array + i)` <=> `*(i + array)` <=> `i[array]`. Of course, you find the last variant only in obfuscated code contests, but it's a testament to what hides behind the surface of C. – cmaster - reinstate monica May 19 '18 at 22:03
  • 2
    @cmaster: nitpick, nitpick... "who learn the English language as a second language". As for the comments regarding C - again, massively off-topic, as much as it itches me to answer you. – einpoklum May 19 '18 at 23:06
  • @einpoklum I was citing your comment at this answer above, which does not include the words "second language". Apparently, I missed the comment where this condition was included, because then I would have refrained from commenting... – cmaster - reinstate monica May 20 '18 at 08:09
  • 2
    @cmaster: It didn't include those words, but that was implied. – einpoklum May 20 '18 at 08:09
  • 2
    This answer describes a good end goal (understanding the language as specified by the standard) but doesn’t seem to have a real recommendation for helping a student reach that point effectively, or how to help the student avoid frustration before that point. – gntskn May 20 '18 at 11:36
  • @gntskn: For that, look at Karl's answer. Answers that help keep people from going down dark alleys and dead ends are still useful, in their own way. – Robert Harvey May 20 '18 at 21:42
  • A fancy way of saying: "Google the error" – RandomUs1r May 21 '18 at 17:05
  • @RobertHarvey I honestly can't see what debug info has to do with compile time errors. And unless you're going for [Real Programmers Don't Use PASCAL ^H^H^H^H^H^H C#](https://www.ee.ryerson.ca/~elf/hack/realmen.html) style parody, I can't see what the "close to the metal" thing is adding to your answer. – npostavs May 22 '18 at 23:07
27

A relevant technique worth mentioning is using a second compiler. Clang has invested in better error messages, for instance, but any alternative way to phrase the error can be enlightening.

This is especially so for the most complex type of errors. For instance, when you mix up two similar constructs (not unusual for beginners), compilers typically have a problem in generating the right error message. This can cause confusion when the compiler gives an error message about the incorrect usage of construct A when you actually intended construct B. A second compiler might infer that you intended B.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
MSalters
  • 8,692
  • 1
  • 20
  • 32
13

Someone made an attempt at a GCC error glossary on Wikibooks a while ago, but it looks like it never quite took off and hasn't been updated.

The "Errors" section is much further along than the "Warnings" section. It looks like it was aimed at G++, but there is still likely to be some information of use to your friend there.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
nBurn
  • 139
  • 3
12

In addition to the above answers, note that most compilers don't have comprehensive error glossaries -- these would be a lot of work to maintain as the messages themselves often change, and there are quite a a lot of them.

The best substitute for a glossary is access to the internet. Whenever the compiler produces an error you do not understand, take comfort that it is highly unlikely that you are the first to have encountered it and been confused. A quick Google of the exact message is often sufficient to give you plenty of information in easy-to-read format, often with example code very similar to your own.

Beyond that, time and familiarity with the language and the compiler is all you need. That, and the good advice given by Karl Bielefeldt.

Tim
  • 202
  • 1
  • 12
Dúthomhas
  • 229
  • 1
  • 5
  • 1
    I don't think it would be a _lot_ of work to maintain. Plus, it can be added to by the public, like Stackoverflow or a Wiki, with trusted people given editor permissions. – einpoklum May 19 '18 at 08:55
  • 6
    @einpoklum Have you ever seen the PHP docs? That's what happens when you let the community take care of that stuff. – Kevin May 19 '18 at 12:37
  • 4
    Once upon a time, published (printed) manuals were the only resource available. They were usually well-enough written to provide the necessary information/guidance to solve a problem. With the evolution of the internet, nobody publishes in print anymore (if at all, it's on-line). The quality of "official" reference material (on-line or otherwise) has fallen considerably over the decades I've been programming, so the best available resource is often Google, and the most useful results often turn up in Stackoverflow. – Zenilogix May 20 '18 at 14:34
  • There remains very high quality references for many languages on the Internet -- C++ in particular. A very complete reference for C++ can be found at cppreference.com, and a more readable but not quite as pedantic ally correct at cplusplus.com. The C++FAQ contains invaluable reading, and I'd you want to spend money on print resources there exist more than a few that will inform you extensively; you can find an excellent list right here on SE. Likewise, the GCC maintains a very extensive set of documentation pages on the net, as does MS. – Dúthomhas May 21 '18 at 04:29
  • 2
    Even if a glossary *does* exist, search engines may be the best way to access them. They're also useful for spotting when you're in uncharted territory: when the only search result is the source code which defines the error message ;) – Warbo May 21 '18 at 11:16
  • 2
    In college, I once got the compiler error "Dave doesn't think this should happen. Please email him at ". I emailed him and in fact I was the first one to have hit that particular error! – user1118321 May 23 '18 at 04:02
6

The C Standard uses a number of terms like "lvalue" and "object" in ways that are different from other programming languages, and compiler messages are often written in such terms. The use of terminology is inconsistent in some parts of the Standard, but anyone wanting to learn C should look at drafts of the C89, C99, and/or C11 standards as well as the rationale documents for them. Searching for e.g. "C99 draft" or "C89 rationale" should work pretty well, though you may need to make sure you get the document you're expecting. Although most compilers support the C99 Standard, it may be useful to know how it differs from the C89 Standard, and the C89 rationale may offer some historical background that later versions don't.

supercat
  • 8,335
  • 22
  • 28
  • 11
    The C standard is a very dense and heavy text. A beginner has no chance of understanding it. – Maya May 19 '18 at 15:22
  • 4
    @NieDzejkob: The terminology used by compilers--which seems to be what the question is about--is derived from the Standard. While you're correct that parts of the Standard are incomprehensible (in part because it's designed by committee, and the authors don't seem to have a consistent understanding of what parts of it are supposed to mean), but anyone wanting to understand what terms like "lvalue" mean should be aware of where they came from. Further, if one wants to understand why something like `x=0x1e-x` yields an error, I really don't know anything other than the Standard... – supercat May 19 '18 at 15:53
  • ...and the rationale that can explain it (the authors thought it was more important to minimize the complexity of the spec than to treat hex constants that happen to end with "e" the same as any others). – supercat May 19 '18 at 15:55
  • 4
    I agree with @NieDzejkob: The C standard is not the kind of text you want to confront a newbie with. Newbies need positive hands-on experiences *fast*. And they need to learn new things one by one as they pop up. Reading a standard or rationale takes way too much time while completely overloading a newbie with information. – cmaster - reinstate monica May 19 '18 at 22:15
  • 2
    @cmaster: I started with the C89 Standard ages ago, and it wasn't too bad even in the days before browsers with a handy 'find text' feature. I'll grant that later standards have gotten worse and worse. While nobody should rely upon the Standard as a sole reference, it's important to recognize the divergence between the folk wisdom about how microcomputer compilers behave, and the ways that the Standard permits low-quality behaviors to behave, so one will be prepared if one has to deal with the latter. – supercat May 19 '18 at 23:15
  • 3
    @cmaster: In any case, someone who is programming C should be aware of the Standard, and know how to consult it when needed, even if they're not going to try to read the whole thing. If one does a web search for a standard library function, for example, one may find a reference that describes one implementation's behavior in some corner cases without mentioning that, from the Standard's point of view, those corner cases invoke Undefined Behavior and other implementations might not work the same way. If one instead searches the Standard, one can avoid that problem. – supercat May 19 '18 at 23:25
  • @supercat Granted: C programmers should know about the standard. But a newbie only needs to know that something like a standard exists. Apart from that, I guess the most important reference resource for newbies will be StackOverflow. And if they want to learn about language details, they need the language-lawyer tag. When it comes to standard functions, I've never looked the up on the internet, I go to the man-pages instead: They are concise, yet very thorough, and they explicitly say which features are GNU-extensions, and what standards are mandating the behavior of the functions. – cmaster - reinstate monica May 20 '18 at 08:21
  • 1
    @cmaster: The man pages describe how the functions work on Unix implementations. The fact that Unix versions happen to support various flag characters for printf, fopen, etc. doesn't mean that they'll work on any non-Unix platforms. – supercat May 20 '18 at 15:16
  • 1
    The C Standard is a wonderful document! And not at all a tough read. Every serious C programmer should read it. – Nick Keighley May 21 '18 at 13:15
5

I'm surprised no one gave the obvious answer and, I suspect, the one most often used in practice: just don't read the error messages.

The vast majority of the value of most error messages is simply that something is wrong on such and such line. Most of the time I just look at the line number and go to that line. My "reading" of the error message at that point is usually just whatever my eye catches in passing, not even a skim. If it is not immediately clear what is wrong on or near the line, then I'll actually read the message. This workflow is even better with an IDE or tooling that highlights errors on the spot, and automatically accomplishes Karl Bielefeldt's suggestion to only consider small changes.

Of course, the error messages don't always point at the appropriate line, but then they often don't point at the appropriate root cause either, so even a full understanding of the error message would be of limited help. It doesn't take long to get an idea of what error messages are more reliable about locating the proper line.

On the one hand, most errors a novice is likely to make are likely to be painfully obvious to an experienced programmer with no help from the compiler being necessary. On the other hand, they are much less likely to be so obvious to the novice (though many will be obvious, most mistakes are stupid mistakes). At this point I agree completely with Robert Harvey, the novice simply needs to become more familiar with the language. There is no avoiding this. Compiler errors that reference unfamiliar concepts or seem surprising should be seen as prompts to deepen ones knowledge of the language. Similarly for cases where the compiler is complaining but you can't see why the code is wrong.

Again, I agree with Robert Harvey that a better strategy for utilizing compiler errors is needed. I've outlined some aspects above and Robert Harvey's answer gives other aspects. It's not even clear what your friend hopes to do with such a "glossary", and it's very unlikely such a "glossary" would actually be of much use to your friend. Compiler messages are certainly not the place for an introduction to the concepts of the language1 and a "glossary" is not that much of a better place for it. Even with a lucid description of what the error message means, it's not going to tell you how to fix the problem.

1 A few languages, like Elm and Dhall (and probably Racket), as well as a few "beginner-oriented" implementations of languages do attempt to do this though. In this vein, MSalters' advice to use a different implementation is directly relevant. I personally find such things uncompelling and not quite aimed at the right problem. This is not to say that there aren't ways of making better error messages, but, to me, they tend to revolve around making the compiler's beliefs and the basis of those beliefs clearer.

Derek Elkins left SE
  • 6,591
  • 2
  • 13
  • 21
4

So, how should a novice programmer approach the challenge of understanding compiler error messages? Specifically, with the combination of C and GCC?

Tell your friend to do the following when encountering an error they don't understand:

  • Remove/comment the code added since the last successful build.
  • Put small parts of it back and compile
  • Repeat until the error occurs

Compiler errors only tell you what the compiler doesn't understand about your code, not what is wrong with it. This approach takes roughly the same amount of time as Googling the error and reading some docs or a StackOverflow post, but gives a much better understanding of what it is that you're doing wrong.

Also make them compile often until they start working on projects that take minutes to build, spotting errors before adding too much other code helps a lot.

Finally, tell them to work on one thing at a time, don't work in multiple files without compiling in between, don't introduce multiple dependencies at once, etc.

Kevin
  • 844
  • 1
  • 7
  • 14
4

Another technique would be for the friend to write his own glossary over time as he encounters different error messages. Often the best way to learn something is to teach it. Of course, by the time the glossary is done, he probably won't need it anymore.

My personal experience with GCC is that each error message relates to a "usual" set of mistakes. For example, when GCC says "did you forget the &" it usually means I forgot parentheses. Of course, which mistakes correspond to which error messages will depend on the programmer, another good reason for the friend to write his own glossary.

Owen
  • 576
  • 3
  • 10
  • 1
    This document has the tremendously important side benefit that it could be put online (even if it only has 5-10 entries) and would be a great differentiator when applying for internships. – Josh Rumbut May 21 '18 at 03:15