On 2018-10-05 23:14 +0200, Josef Wolf wrote:
> On Thu, Oct 04, 2018 at 03:19:56PM -0600, Jeff Law wrote:
> > On 10/4/18 1:39 PM, Josef Wolf wrote:
> > > When gcc inserts trap instructions, it assumes that there is some sort of
> > > hanlder installed for this? How should such a handler look like? I'd rather
> > > have the handler output some useful diagnostics instead of just crashing.
> >
> > It's up to the application to figure out how to handle this situation.
> >
> > The compiler only inserts the traps when it can prove conclusively that
> > the program will trigger undefined behavior at a particular execution point.
>
> I think it's the other way around: the trap is inserted when gcc sees a chance
> for NULL-dereference.
>
> > Stopping the program immediately is far better than the compiler trying
> > to issue diagnostics or anything like that.
>
> I'd very much prefer a warning at compile time! With a warning, I'd have a
> chance to fix the problem before the trap is taken in production.
>
> I fail to see any good in this trap:
In my POV an undefined behavior is just like __builtin_unreachable() because
the compiler can assuems all undefined behaviors are unreachable. It's a
common precedure to use __builtin_trap() instead of __builtin_unreachable()
while debugging:
#ifdef NDEBUG
#define unreachable() __builtin_unreachable()
#else
#define unreachable() __builtin_trap()
#endif
> - If the compiler can detect such a serious problem, then it should emit a
> warning AT COMPILE TIME.
Then we should emit warnings for all "*p" unless we can prove "p" is not NULL.
It's easy to see the proving requires to solve halting problem :).
Don't tell me you will like such warnings to spam you terminal:
warning: undefined behavior may be invoked depending on the content of 's':
r = sscanf(s, "%d", &x);
~~~~~~~^~~~~~~~~~~~
note: according to C1X-N1570 7.21.6.2p10 if 's' is a pointer to the first
byte of '666666666666666666' this would invoke undefined behavior, but we
can't prove 's' is not such a pointer. You may wish to use HOL theorem-
proving system <https://sourceforge.net/projects/hol/> to prove or disprove
this proposition.
> - If the compiler inserts a trap, then this trap should improve the situation
> instead of making it worse.
>
> Simply crashing leaves you without any clue. You have no idea where to look
> for the bug. The crash could even be by a power outage. That's not exactly
> improving the situation.
You have GDB.
> Issuing a diagnostic "Oops, NULL-dereference at adsf.c:123" would improve
> the situation: you know where to look for the fix.
You have -fsanitize=undefined.
> > You're in the world of
> > undefined behavior, the safe thing to do is halt immediately.
>
> Whether stopping immediately is good or not depends very much on the context.
Then what? Just leave it undefined and format your disk, or run a game from
/usr/game? GCC used to do this and then was blamed by a CVE.
> Instead of stopping immediately, I'd also prefer to get something like
> "hey NULL-dereference at foobar.c:123. Stopping now."
You have -fsanitize=undefined. Or you can just wrap this into a macro like
many projects (including GCC itself).
> > That indicates a deeper problem (the existence of the call changing the
> > paths through the program.
>
> The existence of a call to a function with potential side effets (e.g. printf)
> can AND WILL very much change paths due to the fact that the optimizer needs
> to drop some assumptions.
The optimizer just follows the standard. It's not an AI and can't guess what's
in your mind.
> > I'll repeat, if the compiler is inserting traps, the program is horribly
> > buggy at those points. You should dig into why.
>
> If this would be true, then traps in a program that is guaranteed to never
> dereferencing NULL would be an indication of bugs in the compiler?
You can prove many lemmas and theorems to prove a program is guaranteed not to
dereferencing NULL. But the compiler can not. It is designed to compile C
programs according to ISO/IEC 9899, not to prove theorems. The standard does
not require a C compiler to solve halting problem, after all.
This series of article from LLVM blog has answered all of your questions:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
GCC wiki is your friend:
http://gcc.gnu.org/wiki/FAQ#undefinedbut
--
Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
