Feature #1902
open
Function pointer inequality support for calls by function pointers
Added by Pavel Shved over 12 years ago.
Updated over 12 years ago.
Description
Function pointers that may be distpatched to several functions can't be verified correctly even in -fp mode because of the pointer inequality problem. See bug #327 and the test source:tests/files/callfpointer_distpatch.c.
While the generic pointer inequality would definitely be a solution here, we should note that:
- even if pointer inequality is implemented, it may be incomplete and not work for functions;
- function pointer calls are usually distpatched to small amount of functions, so it may be OK to go for an assumption of O(n²) inequalities prior to the GuardedFunctionCall.
- Assignee set to Pavel Shved
- Estimated time set to 4.00 h
Last week I started working on our pointer inequality idea. I needed some infrastructure for that, and I found handy to implement simple function pointer dispatching support first, to check if that infrastructure is viable. However, I got stuck in pointer-calls-related bugs (see 42e572d) that, unfortunately, took most of the allocated time.
I'm close to implementing that O(n²) solution. I guess, I'll do it tomorrow.
- Estimated time deleted (
4.00 h)
Today a tricky issue prevented me from finishing this. In useful-block analysis, it is assumed that there is at lease one "if statement" in each useful block set (which seems correct and doesn't contradict the idea of how programs work). However, GuardedFunctionCall-s are both assumptions and blocks at the same time. They should be split, and only a part of them should get suppressed. There's no obvious way how to lurk this into the code of the related functions.
So far so good, but BLAST's abstract-post does not work when there are both assumption and a block: only the assumption is enforced, and the block is completely omitted. I guess, this capability was lost in an optimization that was made long ago. Though, I'm yet to find where exactly...
Such a configuration was never used without pointer calls, so no wonder this bug remained unnoticed.
Wanted to get some sleep, but couldn't resist the temptation...
Fixed this (bef550d5). We now support function pointers, in a very unoptimized and experimental manner, and with some inevitable bugs yet to unveil, but we do.
This needs some testing, so the feature will reside in function-pointers branch for now.
Also available in: Atom
PDF