> However, that brings up an couple interesting questions. > > Let's say we find a NULL pointer which reaches a return statement in a > function which is marked as returns_nonnull. In that case there is no > dereference. Presumably for that kind of scenario we'll just keep the > builtin trap. > > Similarly, assume we extend this pass to detect out-of-bounds array > indexing. It's fairly simple to do and has always been in my plan. In > that case leaving in the array indexing won't necessarily generate a > fault. For those presumably we'll just want the builtin_trap as well? > > Again, I don't mind inserting a *0, I just want to have a plan for the > other undefined behaviours we currently detect and those which I plan on > catching soon.
The more general problem is that, with -fnon-call-exceptions, we really expect a fully-fledged exception to be raised when something goes wrong. Inserting __builtin_trap doesn't work because it's simply not equivalent to a throw. In other words, if __builtin_throw would be inserted instead of __builtin_trap with -fnon-call-exceptions, things would probably be acceptable as-is. -- Eric Botcazou
