Project

General

Profile

Actions

Feature #1902

open

Function pointer inequality support for calls by function pointers

Added by Pavel Shved about 13 years ago. Updated almost 13 years ago.

Status:
Open
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
10/14/2011
Due date:
% Done:

0%

Estimated time:
Published in build:

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.

Related issues 2 (1 open1 closed)

Related to BLAST - Feature #1886: Function pointer calls if there's only one potential function to call is requiredClosedPavel Shved10/08/2011

Actions
Related to BLAST - Feature #327: Reasoning about pointer inequalities is necessary for analysisOpen08/03/2010

Actions
Actions #1

Updated by Pavel Shved almost 13 years ago

  • 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.

Actions #2

Updated by Pavel Shved almost 13 years ago

  • 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.

Actions #3

Updated by Pavel Shved almost 13 years ago

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.

Actions #4

Updated by Pavel Shved almost 13 years ago

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.

Actions

Also available in: Atom PDF