UB? In My Lexer? [pdf]
open-std.org
UB? In My Lexer? [pdf]
1–4 of 4 posts
Re: UB? In My Lexer? [pdf]
#2“UB? In my lexer?” by Corentin Jabot removes the possibility that just tokenizing C++ code can be a source of undefined behavior in a C++ compiler itself. (Did you know it could be UB? Now it can’t.) Note however that this does not remove all possible UB during compilation; future papers may address more of those compile-time UB sources. ~ Herb Sutter
Re: UB? In My Lexer? [pdf]
#3> Further work will be needed to remove all undefined behavior in [cpp].
The inclusion of this sentence makes me seriously question the author's qualifications. Removing all UB from C++ would be a terrible thing to do that would greatly slow down all C++ programs. If people using C++ were okay with such a slowdown, they'd be using a higher-level language already instead.
Re: UB? In My Lexer? [pdf]
#4> Further work will be needed to remove all undefined behavior in [cpp]. The inclusion of this sentence makes me seriously question the author's qualifications. Removing all UB from C++ would be a terrible thing to do that would greatly slow down all C++ programs. If people using C++ were okay with such a slowdown, they'd be using a higher-level language already instead.
> The inclusion of this sentence makes me seriously question the author's qualifications. Removing all UB from C++ would be a terrible thing to do [...]
So, "[cpp]" here refers not to the C++ language as a whole but rather to the section of the ISO C++ standard governing the behavior of the preprocessor (which is commonly referred to by shorthand as "cpp").
The [cpp] chapter is part of what is amended by this very proposal, and part of the context that the author includes shows another instance of UB in [cpp]. That is what the author is referring to here.
It's just my opinion, but your "qualifications" comment seems needlessly harsh in light of that.