Date: Wed, 29 May 2013 12:32:18 -0500
Howdy!
Three weeks ago, Bjarne sent a short note to the C++ standards reflector
linking to this paper:
http://pdos.csail.mit.edu/papers/ub:apsys12.pdf
The discussion that followed made clear that there was an interest in
doing something about "undefined behavior" in C++.
Modern optimizers have progressed to a point where writing C++ programs
that robustly dodge "undefined behavior" potholes is becoming a
treacherous art, as evidenced by the many examples in the paper cited above
and as documented elsewhere, see references [1]. This is also an
issue for compiler implementers since the 'translation-time evaluation of
user-defined function' feature requires instances of undefined behavior be
diagnosed.
The primary task for SG12 is to conduct a comprehensive investigation
and to propose possible resolutions for undefined and unspecified
behavior in the C++ standards. We are aiming C++17 (the C++14 boat has
already sailed.)
The discussion from the reflector [2] also made clear that "doing something
about 'undefined behavior'" cannot just be a collection of isolated
technical solutions to individual issues. We need a set of general
guidelines for SG12 (and possibly for the Core Working Group) to apply when
proposing resolutions. I welcome suggestions in that regard. This
being a sensitive topic, please be mindful that we need more light than heat.
I would like to have a draft of guidelines, issues and resolutions for
the upcoming Chicago meeting (September 2013.)
[1] http://www.cs.utah.edu/~regehr/papers/overflow12.pdf
https://isc.sans.edu/diary/A+new+fascinating+Linux+kernel+vulnerability/6820
http://blog.regehr.org/archives/759
http://blog.regehr.org/archives/761
http://blog.regehr.org/archives/880
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
[2] See C++ reflector discussion starting with c++std-news-290
-- Gaby
Three weeks ago, Bjarne sent a short note to the C++ standards reflector
linking to this paper:
http://pdos.csail.mit.edu/papers/ub:apsys12.pdf
The discussion that followed made clear that there was an interest in
doing something about "undefined behavior" in C++.
Modern optimizers have progressed to a point where writing C++ programs
that robustly dodge "undefined behavior" potholes is becoming a
treacherous art, as evidenced by the many examples in the paper cited above
and as documented elsewhere, see references [1]. This is also an
issue for compiler implementers since the 'translation-time evaluation of
user-defined function' feature requires instances of undefined behavior be
diagnosed.
The primary task for SG12 is to conduct a comprehensive investigation
and to propose possible resolutions for undefined and unspecified
behavior in the C++ standards. We are aiming C++17 (the C++14 boat has
already sailed.)
The discussion from the reflector [2] also made clear that "doing something
about 'undefined behavior'" cannot just be a collection of isolated
technical solutions to individual issues. We need a set of general
guidelines for SG12 (and possibly for the Core Working Group) to apply when
proposing resolutions. I welcome suggestions in that regard. This
being a sensitive topic, please be mindful that we need more light than heat.
I would like to have a draft of guidelines, issues and resolutions for
the upcoming Chicago meeting (September 2013.)
[1] http://www.cs.utah.edu/~regehr/papers/overflow12.pdf
https://isc.sans.edu/diary/A+new+fascinating+Linux+kernel+vulnerability/6820
http://blog.regehr.org/archives/759
http://blog.regehr.org/archives/761
http://blog.regehr.org/archives/880
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
[2] See C++ reflector discussion starting with c++std-news-290
-- Gaby
Received on 2013-05-29 19:40:20