You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What
We should consider adding a section that describes common occurrences of undefined/unspecified behavior in C++. This section could link to various pieces of C++ documentation as a source if students wanted to read more about specific details. It could also draw attention to the specific behaviors that will be exposed by sanitizers (and the ones that it won't help you with).
Where
Probably belongs in the "Advanced/Extra Tutorials" section of the tutorials. We could link to portions of it in our project specs when there's a issue that we commonly see.
Why
It would provide background information so students can understand when and why they need to enable sanitizers. It also serves as a good introduction to the distinction between language specifications and compiler-specific implementations.
This would be a great resource for macOS users. We use Linux GCC on the autograder and for Windows users. But macOS users use Apple Clang and often come across implementation differences when they submit to the autograder (i.e. "It works on my laptop, why is the autograder failing?"). We have to repeat the same explanation to each student when they come across it for the first time. It would nice if there was a common resource we could point them towards.
Common Apple Clang issues in EECS 280:
Variables are often initialized to 0 for you
Some #include statements seem like they're not needed because another Clang library already #includes it (while the same GCC library does not)
Function parameters are evaluated in a different order than GCC
What
We should consider adding a section that describes common occurrences of undefined/unspecified behavior in C++. This section could link to various pieces of C++ documentation as a source if students wanted to read more about specific details. It could also draw attention to the specific behaviors that will be exposed by sanitizers (and the ones that it won't help you with).
Where
Probably belongs in the "Advanced/Extra Tutorials" section of the tutorials. We could link to portions of it in our project specs when there's a issue that we commonly see.
Why
Common Apple Clang issues in EECS 280:
#includestatements seem like they're not needed because another Clang library already#includes it (while the same GCC library does not)References
https://en.cppreference.com/w/cpp/language/ub