5 ms·

"What's the benefit in learning the ins and outs of undefined behavior?" To force people to learn that making assumptions based on undefined behaviour is dange

by guyzero 10y ago

"What's the benefit in learning the ins and outs of undefined behavior?" To force people to learn that making assumptions based on undefined behaviour is dangerous and that computers are not mind-readers. And you force people to write buffer manipulation code so they realize how good people using other languages have it.

pcwalton 10y ago
> To force people to learn that making assumptions based on undefined behaviour is dangerous and that computers are not mind-readers. You can do that in a lot less time with, say, Array.sort in JavaScript. Explaining that signed overflow is undefined, and why it's undefined, is a whole lot of digression for little gain. > And you force people to write buffer manipulation code so they realize how good people using other languages have it. Seems like a lot of time to spend to make a point that would have been a lot more relevant in 1990 than in 2016.
CJefferson 10y ago
Except, undefined behaviour seems like mostly a C, and C derivates, concept. I teach C, and every year I have a number of students nearly in tears, because somewhere in the huge program they accidentally malloced sizeof(T*) instead of sizeof(T), but of course that causes a crash 10 minutes later in a totally different piece of the code base. My hope (it's not quite there yet, but getting closer) is that things like clang's sanitize modes will reach a point where any undefined behaviour immediately causes an abort. Then students can still figure out what they did wrong, but have a chance of finding the source of their bug.
- mdergosits 10y ago
  Sometimes I use something like: #define ALLOC(n, type) (type)malloc(n sizeof(type)) which makes it harder to have those types of bugs, though not impossible.
- 9248 10y ago
  Speaking as a past student I'm really glad I started with C. In the beginning, the fear of getting some random Segmentation fault out of nowhere actually taught me more than any textbook, school or best practices blog could ever do. It also forced me to learn how to use debuggers :)
  - CJefferson 10y ago
    That's what I tell my students, it's "character building", in the same way playing sports in the rain was as a child for me. Also, many students previously did a course on Java, and clearly never really understood the basics, it's much easier in Java to play "keep tweaking and fixing the exceptions until it works, then don't touch it", particularly for introductory-level projects.
- protomikron 10y ago
  Show them Valgrind. I think if one teaches C to newcomers it is an invaluable tool. If you compile via -g you get nice reports over undefined behaviour, memory leaks, etc. Really I wish I had access to it when I learned C.
  - CJefferson 10y ago
    My experience is that while valgrind is an amazing tool, it's actually not that great for new students. Sometimes it can be misleading, and it doesn't do stack tracking. It's hard to teach students not to over-rely on it, and trust everything it ever states. It seems best to first make them do some horrible debugging by themselves, and then move them onto valgrind late.
    - protomikron 10y ago
      Can you elaborate? I know that it might misbehave (i.e. report false positives), but I only encountered that with more complicated code that deals either with big-fat third party libraries or heavily optimized code where the developer e.g. did not initialize specific variables on purpose. However if you deal with "student" problems I do not think this is the case. E.g. I taught a similar course to students and they appreciated that instead of $ gcc -Wall -std=c99 foo.c $ ./a.out Segmentation Fault they got something like $ gcc -Wall -std=c99 -g foo.c $ ./a.out ... ==22907== Command: ./a.out ==22907== ==22907== Use of uninitialised value of size 8 ==22907== at 0x4004F5: bar (foo.c:42) ==22907== ==22907== Invalid write of size 1 ==22907== at 0x4004F5: bar (foo.c:42) ==22907== Address 0x0 is not stack'd, malloc'd or (recently) free'd ... when e.g. writing to unallocated memory. I know for sure that there were often programs that were believed to be correct by students (and worse, often really worked, but not realiable), but had actually memory errors that were mostly reported by valgrind. I am not proposing to confront them with valgrind's details (I do not even know them), but explain that there is this tool that is a package in every popular Linux distro and ready to use to find these evil memory bugs (and they can be hard to hunt down if you are new to the language). In particular I am interested in a false positive reported by Valgrind for a student exercise.

by guyzero 10y ago

pcwalton 10y ago

> To force people to learn that making assumptions based on undefined behaviour is dangerous and that computers are not mind-readers. You can do that in a lot less time with, say, Array.sort in JavaScript. Explaining that signed overflow is undefined, and why it's undefined, is a whole lot of digression for little gain. > And you force people to write buffer manipulation code so they realize how good people using other languages have it. Seems like a lot of time to spend to make a point that would have been a lot more relevant in 1990 than in 2016.

CJefferson 10y ago

Except, undefined behaviour seems like mostly a C, and C derivates, concept. I teach C, and every year I have a number of students nearly in tears, because somewhere in the huge program they accidentally malloced sizeof(T*) instead of sizeof(T), but of course that causes a crash 10 minutes later in a totally different piece of the code base. My hope (it's not quite there yet, but getting closer) is that things like clang's sanitize modes will reach a point where any undefined behaviour immediately causes an abort. Then students can still figure out what they did wrong, but have a chance of finding the source of their bug.

mdergosits 10y ago
Sometimes I use something like: #define ALLOC(n, type) (type)malloc(n sizeof(type)) which makes it harder to have those types of bugs, though not impossible.
9248 10y ago
Speaking as a past student I'm really glad I started with C. In the beginning, the fear of getting some random Segmentation fault out of nowhere actually taught me more than any textbook, school or best practices blog could ever do. It also forced me to learn how to use debuggers :)
- CJefferson 10y ago
  That's what I tell my students, it's "character building", in the same way playing sports in the rain was as a child for me. Also, many students previously did a course on Java, and clearly never really understood the basics, it's much easier in Java to play "keep tweaking and fixing the exceptions until it works, then don't touch it", particularly for introductory-level projects.
protomikron 10y ago
Show them Valgrind. I think if one teaches C to newcomers it is an invaluable tool. If you compile via -g you get nice reports over undefined behaviour, memory leaks, etc. Really I wish I had access to it when I learned C.
- CJefferson 10y ago
  My experience is that while valgrind is an amazing tool, it's actually not that great for new students. Sometimes it can be misleading, and it doesn't do stack tracking. It's hard to teach students not to over-rely on it, and trust everything it ever states. It seems best to first make them do some horrible debugging by themselves, and then move them onto valgrind late.
  - protomikron 10y ago
    Can you elaborate? I know that it might misbehave (i.e. report false positives), but I only encountered that with more complicated code that deals either with big-fat third party libraries or heavily optimized code where the developer e.g. did not initialize specific variables on purpose. However if you deal with "student" problems I do not think this is the case. E.g. I taught a similar course to students and they appreciated that instead of $ gcc -Wall -std=c99 foo.c $ ./a.out Segmentation Fault they got something like $ gcc -Wall -std=c99 -g foo.c $ ./a.out ... ==22907== Command: ./a.out ==22907== ==22907== Use of uninitialised value of size 8 ==22907== at 0x4004F5: bar (foo.c:42) ==22907== ==22907== Invalid write of size 1 ==22907== at 0x4004F5: bar (foo.c:42) ==22907== Address 0x0 is not stack'd, malloc'd or (recently) free'd ... when e.g. writing to unallocated memory. I know for sure that there were often programs that were believed to be correct by students (and worse, often really worked, but not realiable), but had actually memory errors that were mostly reported by valgrind. I am not proposing to confront them with valgrind's details (I do not even know them), but explain that there is this tool that is a package in every popular Linux distro and ready to use to find these evil memory bugs (and they can be hard to hunt down if you are new to the language). In particular I am interested in a false positive reported by Valgrind for a student exercise.